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ABSTRACT 

The  security  kernel  technology  has  provided  the  technical 
foundation  for  highly  reliable  protection  of  computerized 
information.  However,  the  operating  system  implementations 
face  two  significant  challenges:  providing  (1)  adequate 

computational  resources  for  applications  tasks,  and  (2)  a 
clean,  straightforward  structure  whose  correctness  can  be 
easily  reviewed.  This  paper  presents  the  experience  of  an 
ongoing  security  kernel  implementation  using  the  Advanced 
Micro  Devices  4116  single-board  computer  based  on  the  Z3002 
microprocessor.  The  performance  issues  of  process  switch¬ 
ing,  domain  changing,  and  multiprocessor  bus  contention  are 
explicitly  addressed.  The  strictly  hierarchical  (i.e.. 
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loop-free)  structure  provides  a  series  of  increasingly  capa¬ 
ble,  separately  usable  operating  system  subsets.  Security 
enforcement  is  structured  in  two  layers:  the  basic  kernel 
rigorously  enforces  a  non- discretionary  (viz.,  lattice  mo¬ 
del)  policy,  while  an  upper  layer  provides  the  access  re¬ 
finements  for  a  discretionary  policy. 

BACKGROUND 

For  the  last  two  and  a  half  years  the  Naval  Postgraduate 
School  has  been  conducting  a  research  and  development  pro¬ 
ject  involving  security  kernel  based  operating  systems  de¬ 
signed  for  multiple  processor  implementations.  As  this  work 
continues  we  feel  that  it  is  important  to  report  on  our  pro¬ 
gress  and  experiences,  especially  in  the  area  of  micropro¬ 
cessor  implementations. 

This  effort  has  come  to  be  known  as  the  "SASS"  or  Secure 
Archival  Storage  System  project  [1],  In  fact,  this  is  a 
misnomer,  as  SASS  is  but  a  single  instance  of  a  more  general 
family  of  secure  operaring  systems  designed  early  in  the 
project  [2].  While  SASS  has  been  the  object  of  the  majority 
of  the  research  reported  it  is  not  the  only  implementation. 
Another  operating  system  of  this  family  has  also  been  writ¬ 
ten  to  support  a  signal  processing  system  that  uses  multiple 
Intel  3086  processors  [3]. 
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SASS  has  been  our  principal  testbed  for  exploring  the  im¬ 
plementation  and  performance  issues  related  to  these  types 
of  operating  systems.  SASS  itself  was  designed  to  be  a  com¬ 
prehensive  multiuser,  multilevel  secure  file  storage  system. 
As  designed,  it  will  consist  of  a  small  number  of 
Z8000-based  [4]  single  board  computers  sharing  a  single  Mul¬ 
tibus  with  storage  devices  and  input/output  devices.  SASS 
will  interface  via  bidirectional  lines  to  a  number  of  "host" 
systems,  as  illustrated  in  Figure  1.  SASS  will  provide  each 
host  with  a  hierarchical  file  system.  This  system  can  be 
used  to  store  and  retrieve  files,  and  share  files  with  other 
hosts.  This  design  will  allow  SASS  to  serve  as  a  central 
hub  of  a  data  secure  network  of  computers  with  diverse  se¬ 
curity  authorization  for  sensitive  information.  SASS  pro¬ 
vides  archival,  shared  storage  while  insuring  that  each  in¬ 
terfaced  host  processor  can  access  only  that  information 
appropriate  to  its  security  authorizations. 
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Figure 


SASS  System  Interfaces 
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STRUCTURE 


For  this  family  of  operating  systems  the  security  kernel 
technology  has  been  used  not  only  to  effect  security  bur 
also  to  provide  the  underlying  organizational  framework  for 
the  operating  system.  The  SASS,  one  member  of  this  family, 
is  in  the  final  stages  of  implementation.  This  development 
experience  has  highlighted  the  importance  of  several  fea¬ 
tures  that  are  key  to  this  family: 

-  The  pervasive,  yet  systematizing  impact  of  the  security 
kernel  methodology  [5]. 

-  The  design  simplicity  that  accompanies  a  loop-free  mo¬ 
dularization  that  is  highly  compatible  with  the  resource 
sharing  and  multiprogramming  functions. 

-  The  significance  of  a  high  degree  of  configuration  in¬ 
dependence,  particularly  for  the  ability  to  use  the  latest 
microprocessors  for  testbed  implementation. 

Independent  of  security,  this  particular  kernel  structure 
is  attractive  as  a  canonical  operating  system  interface.  It 
appears  adequate  for  a  wide  range  of  functionality  and  ca¬ 
pacity,  and  it  evidences  a  high  degree  of  independence  from 
hardware  idiosyncrasies.  These  operating  system  features 
will  be  discussed  further  below. 


Members  of  this  operating  system  family  are  organized 
with  three  distinct  extended  machine  layers:  (1)  the  secur¬ 
ity  kernel,  (2)  the  supervisor,  and  (3)  the  applications. 
This  is  illustrated  in  Figure  2.  The  concept  of  a  hierarchy 
of  extended  machines  is,  to  be  sure,  not  new;  however,  the 
security  kernel  significantly  constrains  the  organization. 
In  particular,  for  reason  of  security  all  the  management  of 
physical  resources  must  be  within  the  kernel  itself.  Furth¬ 
ermore,  confidence  is  increased  by  keeping  the  kernel  as 
small  and  simple  as  possible.  This  means  that  much  of  what 
is  commonly  thought  of  as  the  operating  system  is  provided 
outside  the  kernel  in  the  supervisor  layer.  For  this  parti¬ 
cular  family  member  there  is  no  major  applications  layer 
(viz.,  within  SASS  itself),  since  the  applications  are  con¬ 
tained  in  the  individual  hosts. 

The  basic  family  of  operating  systems  requires  the  ker¬ 
nels  to  provide  extended  virtual  machines  that  specifically 
support  both  asynchronous  processes  and  segmented  address 
spaces.  Within  SASS,  the  kernel  virtualizes  processors,  all 
levels  of  storage,  and  input/output.  The  kernel  creates 
virtualized  objects  --  processes,  segments,  and  devices.  It 
is  this  "pure"  virtual  interface  that  is  attractive  as  the 
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Figure  2:  Extended  Machine  Layers 


basis  for  canonical  operating  system  features.  The  SASS  su¬ 
pervisor  is  in  turn  built  upon  the  kernel,  using  these  vir¬ 
tualized  objects  to  construct  the  file  system. 

Both  the  kernel  and  the  supervisor  have  certain  responsi¬ 
bilities  for  system  security.  The  kernel  manages  all  physi¬ 
cal  resources,  and  the  kernel  is  distributed  (i.e.,  includ¬ 
ed)  in  the  address  space  of  every  process.  At  this  level, 
isolation  of  the  kernel  —  protection  from  users  and  the  su¬ 
pervisor  --  must  be  provided  by  hardware  enforced  domains. 
The  design  of  the  system  is  strictly  hierarchical  (viz.,  the 
kernel  is  more  privileged  than  the  supervisor)  so  protection 
rings,  as  defined  for  Multics  (6],  are  a  satisfactory  domain 
implementation. 

The  kernel  has  the  responsibility  for  the  enforcement  of 
access  limitations:  that  is,  the  kernel  provides  the  mechan¬ 
ism  for  supporting  non-discretionar y  security  policy.  The 
SASS  kernel  can  support  any  such  policy  which  can  be  ex¬ 
pressed  by  a  lattice  of  access  classes  [7J.  Every  object  — 
process,  segment,  or  device  —  has  a  non-forgable  label  that 
denotes  its  access  class.  This  non-discretionary  security 
has  been  parameterized  in  SASS  such  that  exactly  one  module 
has  knowledge  of  the  interpretation  of  this  label  in  terms 
of  a  specific  policy.  Thus,  only  this  single  module  need  be 
tailored  to  support  a  particular  policy. 
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SASS  provides  discretionary  security  (shared  access 
within  the  bounds  of  non-discretion  ary  policy  based  on  indi¬ 
vidual  user  identification)  via  the  supervisor  and  the  file 
structure.  This  discretionary  security  is  completely  out¬ 
side  of  the  kernel  (in  contrast  with  the  KSOS  [8]  approach). 

The  supervisor  handles  the  "Secure  Beader- Writer  Problem" 
with  a  non-excl usionary  approach  (one  writer,  retry  on  read) 
to  provide  synchronization  between  processes  of  different 
access  classes.  This  control  of  interprocess  communication 
is  implemented  via  kernel  primitives  using  Reed’s  event- 
counts  and  sequencers  [9], 

The  SASS  supervisor  capabilities  are  achieved  by  associ¬ 
ating  two  processes  with  each  host  link.  These  processes 
access  that  portion  of  the  SASS  file  structure  associated 
with  that  host.  One  of  these  processes  provides  I/O  tran¬ 
smission  and  link  management,  while  the  other,  a  file  manag¬ 
er,  is  responsible  for  the  file  system  structure  of  its  as¬ 
sociated  host.  Communication  between  these  processes  (as  is 
communication  between  all  processes)  is  achieved  using 
shared  segments  --  a  mailbox.  Synchronization  is  provided 
by  the  kernel  (with  eventcounts  and  sequencers). 

The  complementary  kernel/supervisor  approach  to  security 
has  several  advantages  for  SASS:  the  size  and  the  complexi- 
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ty  of  the  kernel  can  be  minimized,  and,  given  reliable  host 
authentication,  any  host  weaknesses  will  not  impact  the  re¬ 
liable  enforcement  of  the  non-discretionary  security  policy. 

The  security  kernel  approach  constrains  not  only  the  in¬ 
terface  but  also  the  detailed  design  and  implementation  of 
internal  state  variables.  The  problem  is  to  prevent  indi¬ 
rect  information  paths  between  processes  with  different  ac¬ 
cess  classes.  We  address  this  problem  using  essentially  the 
approach  detailed  by  Hillen  [10],  although  without  the  rigor 
of  a  proof.  Internal  state  variables,  e.g.,  shared  resource 
tables,  are  assigned  an  access  class,  and  it  is  confirmed 
that  its  values  will  not  be  reflected  to  processes  of  an  in¬ 
consistent  access  class.  The  most  apparent  result  is  that 
the  "success  code"  (returned  in  response  to  tne  invocation 
of  kernel  primitives)  primarily  reflects  the  state  of  the 
per-process  virtual  resources,  not  the  shared  physical  re¬ 
sources. 
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Loop  Free  Organ ization 

Another  aspect  of  the  design  that  has  helped  to  keep  the 
security  kernel  simple  and  understandable  is  the  loop-free 
structure  of  SASS.  The  loop-free  design  supports  the  soft¬ 
ware  engineering  concept  of  "information  hiding"  [ 1 1  ],  as 
there  are  really  no  global  data  structures  within  SASS.  The 
kernel  is  internally  organized  into  four  distinct  layers,  as 
illustrated  in  Figure  3;  these  layers,  that  will  be  de¬ 
scribed  below,  are  termed  (1)  segment  and  event  managers, 
(2)  traffic  controller,  (3)  memory  manager,  and  (4)  inner 
traffic  controller. 

In  practice  we  have  been  quite  doctrinaire  in  enforcement 
of  the  loop-free  structure  for  this  organization.  While 
many  operating  systems  claim  to  be  modular  or  well-struc¬ 
tured,  we  empirically  validate  this  claim.  We  "peel-off" 
the  upper  layers  one  at  a  time  by  literally  removing  the 
code  and  data,  and  then  demonstrate  that  the  remainder  can 
be  loaded  and  run  as  a  functionally  intact,  but  obviously 
limited,  operating  system  subset.  The  function  of  each  lay¬ 
er  will  now  be  described,  proceeding  from  the  bottom  upward. 
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F  i  g  ur  e  3  : 


I Traffic  Controller.  Processor  multiplexing  has  two 
layers,  similar  to  those  proposed  for  Multics  [12].  Each 
physical  processor  has  a  fixed  number  of  "virtual  proces¬ 
sors"  that  are  multiplexed  onto  it.  Two  of  these  virtual 
processors  are  dedicated  to  system  services:  an  idle  virtu¬ 
al  processor  and  a  memory  manager  process  to  manage  the  as¬ 
ynchronous  access  to  secondary  storage  devices.  The  remain¬ 
ing  virtual  processors  (currently  two  per  physical 
processor)  are  available  to  the  (upper  level)  traffic  cont¬ 
roller.  The  inner  traffic  controller  provides  signal  and 
wait  synchronization  primitives  that  include  a  message  that 
is  passed  between  virtual  processors.  In  terms  of  tradi¬ 
tional  jargon,  the  inner  traffic  controller  provides  multi¬ 
programming  by  scheduling  virtual  processors  to  run  on  the 
CPO  they  are  (permanently)  associated  with.  Note  that  this 
structure  implies  that  the  security  kernel  is  interruptible, 
viz.,  is  not  a  critical  section;  however,  the  inner  traffic 
controller  itself  is  not  interruptible.  In  addition,  this 
layer  provides  all  the  multiprocessing  interactions  between 
individual  physical  processors,  using  a  hardware  "preempt" 
interrupt. 

Memory  Manager.  This  layer  manages  the  multiplexing  of  the 
physical  storage  resources,  viz.,  "disk"  and  "core".  This 
layer  also  manages  the  segment  descriptors  in  the  memory 
management  unit  (MMU)  image  for  each  process.  Most  of  the 


functions  of  this  layer  are  executed  by  the  per-CPU  memory 


manager  processes,  with  synchronization  provided  by  inner 
traffic  controller  signal  and  wait  primitives.  The  single 
board  computers  have  per-processor,  local  memory;  there  is 
also  additional  global  memory  that  is  addressable  by  all 
processes.  The  memory  manager  insures  that  (only)  shared 
segments  are  in  global  memory. 

This  policy  can  require  some  transfers  between  local  and 
global  memory;  however,  the  low  transaction  rate  of  the  ar¬ 
chival  storage  system  is  not  demanding,  and  this  structure 
minimizes  bus  transfer  requirements  under  expected  operating 
conditions. 

Traffic  Controller.  The  variable  number  of  processes  (two 
per  host)  are  multiplexed  onto  virtual  processors  defined  by 
the  inner  traffic  controller.  Each  process  has  an  affinity 
to  the  physical  processor  whose  local  memory  contains  a  por¬ 
tion  of  its  address  space  at  the  time  of  the  process  sche¬ 
duling  decision.  As  indicated  earlier,  the  traffic  cont¬ 
roller  layer  uses  Reed's  advance  and  await  mechanism  [9]  to 
provide  interprocess  communication. 

Segment  and  Event  Managers .  All  entries  into  the  kernel 
pass  through  the  segment/event  manager  layer.  The  explicit 
non-discretionary  security  checks  are  made  at  this  level  by 
comparing  the  access  class  labels  of  subjects  and  objects. 
This  layer  uses  a  per-process  known  segment  table  to  convert 
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process  local  names  (viz.,  segment  number)  for  objects  into 
system-wide  names.  Each  segment  has  associated  with  it  two 
eventcounts  and  a  sequencer;  thus,  segment  numbers  also 
serve  as  their  names.  The  segment  manager  provides  for  the 
creation  and  deletion  of  segments  and  their  entry  into  and 
removal  from  a  process  address  space. 

Gat®  A  process  invokes  a  security  kernel  function 

using  the  traditional  trap  mechanism.  The  Z8000  ’’system 
call"  instruction  causes  a  trap,  and  the  gate  keeper  is 
merely  the  trap  handler.  All  parameters  and  return  values 
are  "passed  by  value"  in  CPU  registers;  this  simplifies  se¬ 
curity  validation.  The  gate  keeper  merely  calls  the  parti¬ 
cular  procedure  that  corresponds  to  the  requested  function. 
Microprocessor  Testbed 

One  important  aspect  of  this  research  has  been  the  actual 
implementation  and  testing  of  the  concepts  developed.  Trad¬ 
itionally  the  implementation  of  multiple  processor  struc¬ 
tures  has  been  an  expensive  undertaking.  Recently  the  de¬ 
velopment  of  sophisticated  microprocessors  that  feature 
multiple  operating  modes,  advanced  addressing,  support  of 
multiple  processor  configurations,  and  a  standard  bus  co¬ 
nfiguration  with  peripheral  support  have  all  made  the  imple¬ 
mentation  of  advanced  operating  systems  on  microprocessor 
devices  possible,  and  economically  feasible. 
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The  processors  of  SASS  all  share  the  same  bus;  each 
processor  is  a  commercial  single  board  computer  with  on¬ 
board  random  access  memory.  These  processors  also  share  a 
global  memory,  and  certain  peripheral  devices.  This  co¬ 
nfiguration  is  illustrated  in  Figure  4. 

In  general,  security  kernel  based  operating  systems  find 
three  processor-supported  execution  domains  (operating 
states)  highly  desirable:  for  the  kernel,  supervisor,  and 
applications.  This  is  true  of  the  operating  system  family 
discussed  here.  Currently  there  are  no  single  chip  proces¬ 
sors  that  support  three  states.  This  is  not  a  significant 
problem  for  SASS,  since  it  is  the  hosts  rather  than  the  SASS 
system  processors  that  execute  user  application  programs. 
Under  these  circumstances  a  two  mode  (kernel  and  supervisor) 
machine  is  sufficient.  Such  architectures  are  currently 
available  as  microprocessors,  in  particular  the  Z300Q. 

Accordingly,  we  are  implementing  a  multiple  microproces¬ 
sor  system  to  test  the  SASS  concept.  The  current  hardware 
in  use  is  the  AMD  4116  single  board  computer  £13]  in  a  stan¬ 
dard  Multibus  backplane.  This  configuration  has  a  signifi¬ 
cant  limitation:  it  does  not  include  the  hardware  Memory 
Manager  Unit,  as  described  in  [2]. 
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Figure  4:  Multiprocessor  Configuration 
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Currently  we  simulate  in  software  the  memory  management 
unit,  so  the  kernel  is  not  protected  from  the  supervisor  as 
the  original  design  specified.  Hardware  protection  in  the 
form  of  addressing  limitations  is  available,  and  has  been 
used  in  some  of  the  experiments  to  assure  the  integrity  of 
the  kernel.  In  this  configuration,  the  hardware  protects 
one  half  of  the  local  memory  from  any  access  when  the  CPCJ  is 
operating  in  the  normal  mode.  Any  attempt  to  access  memory 
which  is  thus  protected  generates  an  interrupt  and  the  fault 
detection  software  traps  the  access.  This  is  adequate  for 
current  tests,  but  a  complete  memory  management  system  is 
clearly  more  desirable.  Our  experiences  on  this  testbed  in 
terms  of  performance  and  software  development  are  discussed 
further  below. 

THE  SASS  EXPERIENCE 


The  lessons  learned  to  this  point  fall  into  two  broad  ca¬ 
tegories:  programming  (software  engineering)  experiences, 
and  performance  experiences.  He  will  discuss  both  of  these 
issues  below. 

Programming  Experiences 


The  nature  of 
tured,  emphasizing 
software  design  is 


effort  has 
at  every 
strictly  "top-down". 


been  highly  struc- 
opportunity.  The 
This  has  been  a 


this  research 
modularity 
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matter  of  good  design  practice,  and  of  necessity.  Since  the 
majority  of  the  work  has  been  performed  by  a  succession  of 
Master's  degree  students  [14,15,16,17,18,19]  during  their 
brief  six  to  nine  months  of  research  each,  the  clear  defini¬ 
tion  of  software  modules  has  been  key  to  the  success  of  the 
effort.  We  have  found  that  the  high  degree  of  modularity 
has  allowed  the  students  to  work  on  the  project  with  a  mini¬ 
mum  of  "start-up"  time,  and  a  maximum  of  productive  effort 
and  learning. 

The  actual  implementation  is  proceeding  in  an  essentially 
bottom  up  manner,  with  test  harnesses  and  stubs  being  writ¬ 
ten  as  necessary  for  testing.  The  SASS  modules  were  speci¬ 
fied  in  a  pseudo-language  resembling  current  higher  level 
languages.  The  SASS  modules  as  implemented  were  coded  in 
PLZ-ASM  [20],  the  Z8000  structured  assembly  language.  We 
found  that  the  pseudo-code  specifications  of  modules  were 
adequate,  and  that  the  translation  from  this  code  to  the 
structured  assembly  language  was  straightforward. 

The  structured  assembly  language  of  the  Zilog  Z8000  sup¬ 
ported  many  of  the  constructs  usually  thought  to  be  unique 
to  higher  level  languages,  including  typed  record  struc¬ 
tures,  DO-loops,  IF-THEN-ELSE ,  and  CASE.  In  fact,  our  pro¬ 
grammers  think  of  this  assembly  language  as  a  higher  level 
language.  Approximately  40  percent  of  the  statements  writ- 
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ten  in  SASS  are  equivalent  to  statements  in  modern  program¬ 
ming  languages. 

Despite  the  qualities  of  the  structured  assembler,  it  was 
selected  by  default.  When  the  decision  was  made,  the  proto¬ 
type  hardware  boards  were  just  becoming  available.  There 
was  virtually  no  software  support  available.  In  particular, 
no  higher  level  language  was  available.  The  software  envi¬ 
ronment  was  (by  modern  standards)  very  primitive,  with  no 
tools  for  operating  system  development  available.  Neverthe¬ 
less,  the  progression  from  microprocessor  development  system 
to  commercial  single  board  computer  system  has  been  surpris¬ 
ingly  smooth  (an  opinion  that  some  students  might  dispute) . 
The  software  development  environment  has  grown  slowly.  Yet, 
this  has  not  proved  to  be  a  handicap. 
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Issues 

In  the  programming  for  the  SASS,  we  have  generally  treat¬ 
ed  performance  as  a  secondary  issue,  in  deference  to  more 
basic  concerns  such  as  security  and  modularity.  However,  we 
have  addressed  performance  on  a  design  level  where  perfor¬ 
mance  is  strongly  related  to  architectural  choices. 

Obviously,  one  basic  design  choice  is  the  use  of  multi¬ 
processing  as  a  way  to  increase  processing  capacity.  Howev¬ 
er,  bus  contention  is  a  major  performance  concern  in  the 
multiprocessor  configurations,  since  all  processors  share  a 
single  Multibus.  If,  for  example,  all  code  and  data  were 
located  in  global  memory,  then  even  two  or  three  processors 
would  saturate  the  bus.  However,  in  reality  only  shared, 
writable  segments  need  be  in  global  memory.  Dur  use  of  a 
purely  virtual,  segmented  memory  permits  the  kernel  to  det¬ 
ermine  exactly  which  are  the  shared,  writable  segments.  As 
noted  before,  the  memory  manager  layer  totally  controls  the 
allocation  to  global  memory,  and  thus  markedly  controls  bus 
contention. 

In  the  current  SASS  implementation  we  use  the  "Normal" 
and  "System"  modes  of  the  28000  hardware,  with  the  system 
mode  dedicated  to  the  security  kernel.  The  domain  changes 
automatically  generate  a  switch  of  the  stack  within  the 
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hardware. 


This  is  particularly  important  to  the  efficiency 
with  which  we  can  switch  domains  while  maintaining  the  in¬ 
tegrity  of  the  kernel. 

In  SASS  a  process  switch  is  achieved  by  switching  the 
stack.  SASS  saves  the  process  history  in  the  stack,  so  a 
switch  requires  only  the  stack  exchange.  Preempt  hardware 
interrupts  can  initiate  scheduler  changes,  and  associated 
virtual  interrupts  to  the  virtual  processors.  This  sequence 
is  relatively  efficient  given  the  Zilog  architecture.  The 
process  switching  performance  question  is  more  interesting 
in  the  context  of  processor  multiplexing. 

The  multiprogramming  time  is  the  interval  from  the  time 
the  inner  traffic  controller  signal  primitive  is  invoked  in 
one  virtual  processor  until  there  is  a  return  from  a  (pend¬ 
ing)  wait  invocation  in  a  different  virtual  processor.  This 
includes  both  process  switching  and  message  passing  opera¬ 
tions. 

For  interprocess  communication,  the  read  and  ticket  calls 
(from  the  normal  mode)  include  a  system  call  though  the  gate 
keeper  to  the  kernel,  the  non-discretionary  security  checks, 
and  access  to  the  eventcount  or  sequencer  value;  however,  no 
process  switch  is  involved.  The  synchronization  time  in¬ 
cludes  the  interval  from  the  invocation  of  the  system  call 
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(in  normal  mode)  for  advance  in  one  process  until  the  return 
from  a  (blocking)  await  invocation  in  a  different  process. 
This  includes  the  security  checks  and  scheduling  of  both  a 
virtual  and  a  physical  processor. 

A  set  of  measurements  on  the  current  implementation  are 
summarized  in  Table  1.  There  has  been  no  effort  to  "tune” 
the  system  to  improve  performance.  He  find  these  results 
within  our  range  of  expectations  for  a  single  chip  micropro¬ 
cessor. 


Function 


Time  (milliseconds) 


a ulti programming 

signal/wait  pair 


0.5 


Synchronization 

advance/await  pair 


2.3 


Read  (Eventcount) 


0.6 


Ticket  (Sequencer) 


0.6 


Table  1.  Performance  Measurements 
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SUMMARY 


A  modern  operating  system  featuring  kernel  based  securi¬ 
ty,  segmented  memory  and  multiple  processors  has  been  de¬ 
signed  and  is  being  implemented  using  modern  microproces¬ 
sors.  To  date  our  focus  on  methodical  design  has  paid  off: 
the  implementation  of  a  carefully  designed,  simple  structure 
using  elementary  software  development  tools  has  proceeded 
well. 

The  initial  testbed  implementation  is  running  and  prelim¬ 
inary  data  is  now  available  regarding  the  operating  perfor¬ 
mance  of  such  systems  implemented  on  microprocessors  of  ad¬ 
vanced  architectures.  Data  gathered  suggests  that  the 
security  kernel  is  indeed  an  attractive  structure  for  a  mo¬ 
dern  operating  system.  There  is  a  wide  range  of  applica¬ 
tions  where  sophisticated  operating  systems  can  be  imple¬ 
mented  upon  microprocessors,  and  attractive  performance  can 
be  achieved,  particularly  through  the  use  of  multiple  pro¬ 
cessors. 
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FOREWOR 0 


This  technical  report  contains  edited  segments  of  four  mas¬ 
ters'  theses: 

The  Design  and  Implementation  of  the  Memory  Manag¬ 
er  for  g  Secure  Archival  Storage  System  by  E.  E. 

Moore  and  A.  V.  Gary 

la  Implementation  of  Multiprogramming  agd  Process 
Management  for  a  Security  K^rnej,  Operat ing  System 
by  S.  L.  Reitz 

Implementation  of  Segment  Management  for  a  Secure 
Archival  Storage  System  by  J.  T.  Wells 

Implementation  of  Process  Management  for  a  Secure 
archival  Storage  System  by  A.  E.  Strickler 

which  describe  the  development  and  implementation  of  the  Na¬ 
val  Postgraduate  School  Secure  Archival  Storage  System 
(SASS)  .  These  theses  are  based  upon  the  design  outlined  in 
the  Naval  Postgraduate  School  SECURE  ARCHIVAL  STORAGE  SYSTEM 
Part  I  -  Design  -  by  R.  R.  Schell  and  L.  A.  Cox  [17].  This 
design  is  updated  and  presented  in  detail. 

Some  sections  of  each  thesis  have  been  excluded  in  order 
to  eliminate  repetition  and  bulk.  Similarly,  the  program 
listings  in  this  report  represent  the  current  state  of  the 
project  and  do  not  pertain  to  any  one  thesis.  An  attempt 
has  been  made  to  footnote  some  discrepancies  between  the 
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system  described  by  these  theses  and  the  current  state. 
However,  there  may  be  some  details  described  herein  which  do 
not  correspond  to  the  current  SASS  system.  Consequently, 
the  reader  is  advised  to  consult  the  individual  thesis  if 
more  detail  on  a  particular  phase  of  the  development  is  re¬ 
quired.  A  program  description  document,  providing  greater 
clarification  of  SASS  organization  and  listings,  is  also 
a  vailable. 
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PAST  A 

IHTRODUCTION 


Chapter  I 
BACKGROUND 

This  chapter  is  an  updated  excerpt  from  Implemen¬ 
tation  of  Segment  Management  for  a  Secure  Archival 
Storage  System  by  J.  T.  Wells  [20]. 

O'Connell  and  Richardson  provided  the  design  for  a  fami¬ 
ly  of  secure,  distributed,  multi-microprocessor  operating 
systems  from  which  the  subset,  SASS,  was  later  derived  [7], 
In  their  work,  two  of  the  primary  motivations  were  to  pro¬ 
vide  a  system  that  (1)  effectively  coordinated  the  process¬ 
ing  power  of  microprocessors  and  (2)  provided  information 
security . 

The  basis  for  emphasis  on  utilization  of  microprocessors 
is  not  purely  that  of  replacing  software  with  more  powerful 
(and  faster)  hardware  (microprocessors)  but  is  also  an  eco¬ 
nomic  issue.  Software  development  and  computing  operations 
are  becoming  more  and  more  expensive,  putting  further  pres¬ 
sure  on  system  designers  to  increasingly  utilize  people 
solely  for  system  functions  that  computers  cannot  perform  in 
a  cost  effective  manner.  Microcomputers,  on  the  other  hand, 
are  becoming  less  and  less  expensive  and  ace,  therefore,  in¬ 
creasingly  being  used  for  more  functions. 

The  need  for  information  security  has  been  gradually  re¬ 
cognized  as  the  uses  of  computers  have  expanded.  As  security 
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needs  for  specific  computer  systems  have  been  recognized, 
attempts  have  been  made  to  modify  the  existing  systems  to 
provide  the  desired  security.  The  results  have  been  systems 
that  could  nor  be  certified  as  secure  and/or  which  have 
failed  to  resist  penetration  efforts,  i.e.  systems  which,  in 
effect,  did  not  provide  adequate  information  security.  It 
has  become  clear  that,  in  order  to  be  certifiably  secure,  a 
computer  system  must  have  security  designed  in  from  first 
principles  [10,11].  Such  is  the  case  with  SASS.  Information 
security  was  and  continues  to  be  a  chief  design  feature. 
Integral  to  the  design  goal  of  information  security  were  two 
related  goals.  One  of  these  goals  was  to  provide  multilev¬ 
el  controlled  access  to  a  consolidated  warehouse  of  data  for 
a  network  of  multiple  host  computers.  The  other  key  goal  was 
to  provide  for  controlled  sharing  among  the  computer  hosts. 

A  brief  background  of  prior  work  relative  to  SASS  fol¬ 
lows.  O'Connell  and  Richardson  originated  the  design  of  a 
secure  family  of  operating  systems.  Their  design  provided 
two  basic  parts  for  their  system  —  the  supervisor  (to  pro¬ 
vide  operating  system  services)  and  the  kernel  (to  provide 
for  physical  resource  management) .  The  design  of  the  SASS 
supervisor  was  completed  by  Parks  [9].  No  implementation  or 
further  design  effort  on  the  supervior  has  followed,  to 
date.  The  initial  design  of  the  kernel  was  completed  by 
Coleman  [2].  That  design  described  the  kernel  in  terms  of 
seven  modules: 
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1.  Gate  Keeper  Module  —  provided  for  ring-crossing  me¬ 
chanism  and  thus  isolation  of  the  kernel. 

2.  Segment  Manager  Module  --  provided  for  management  of 
segmented  virtual  memory. 

3.  Traffic  Controller  Module  —  multiplexed  processes 
onto  virtual  processors  and  supports  the  inter-  pro¬ 
cess  communication  primitives  Block  and  Makeup. 

4.  Mon-Discretionary  Security  Module  --  mediated  non- 
discretionary  security  access  attempts. 

5.  Inner  Traffic  Controller  Module  --  multiplexed  virtu¬ 
al  processors  onto  real  processors  and  provided  the 
Kernel  synchronization  primitives  Signal  and  Bait. 

6.  Memory  Manager  Module  —  managed  main  memory  and  sec¬ 
ondary  storage. 

7.  Input-Output  Manager  —  managed  the  moving  of  infor¬ 
mation  to  external  devices  outside  the  boundaries  of 
the  SASS. 

Refinement  of  the  kernel  design  and  partial  implementation 
was  completed  by  Gary  and  Moore  [5]  in  conjunction  with 
Reitz  [12].  The  resultant  description  of  the  kernel  as  a  re¬ 
sult  of  their  work  was: 

1.  Gate  Keeper  Module 

2.  Segment  Manager  Module 

3.  Event  Manager  Module  —  worked  with  the  Traffic  Cont¬ 
roller  to  manage  the  event  data  associated  with  the 
IPC  mechanism  of  eventcounts  and  sequencers. 

4.  Non-Discret ionary  Security  Module 

5.  Traffic  Controller  Module  —  replaced  Block  and  Make¬ 
up  with  Advance  and  Await  (to  implement  Supervisor 
IPC  mechanism  of  eventcounts  and  sequencers). 

6.  Memory  Manager  Module 

7.  Inner  Traffic  Controller  Module 
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Reitz  implemented  the  Traffic  Controller  Module  and  Inner 
Traffic  Controller  aodule.  Gary  and  Moore  completed  a  de¬ 
tailed  design  of  the  Memory  Manager,  originated  the  Memory 
Manager  code  (written  predominantly  in  PLZ/SYS),  selected  a 
thread  of  the  code,  hand  compiled  it  into  PLZ/ASM  and  ran  it 
on  the  Z8000  developmental  module.  Wells  provided  the  im¬ 
plementation  of  the  Segment  Manager  and  Non-Discretionar y 
Security  Modules  as  well  as  partial  implementation  of  Dis¬ 
tributed  Memory  Manager  functions.  Strickler  refined  and 
implemented  the  process  management  functions  for  the  SASS 
(written  in  PLZ/ASM) . 
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Chapter  II 

BASIC  CONCEPTS/D EF INITIO MS 

This  chapter  is  an  excerpt  from  Implementation  of 
Procass  Management  for  a  Secure  Archival  Storage 
System  by  A.  B.  Strickler  [19].  Minor  changes 
have  been  made  for  integration  into  report. 

This  section  provides  an  overview  of  several  concepts 
essential  to  the  SASS  design.  Readers  familiar  with  SASS  or 
with  secure  operating  system  principles  may  wish  to  skip  to 
the  next  section. 

A.  PROCESS 

The  notion  of  a  process  has  been  viewed  in  many  ways  in 
computer  science  literature.  Organick  [8]  defines  a  process 
as  a  set  of  related  procedures  and  data  undergoing  execution 
and  manipulation,  respectively,  by  one  of  possibly  several 
processors  of  a  computer.  Madnick  and  Donovan  [6]  view  a 
process  as  the  locus  of  points  of  a  processor  executing  a 
collection  of  programs.  Reed  [10]  describes  a  process  as 
the  sequence  of  actions  taken  by  some  processor.  In  other 
words,  it  is  the  past,  present,  and  future  "history11  of  the 
states  of  the  processor.  In  the  SASS  design,  a  process  is 
viewed  as  a  logical  entity  entirely  characterized  by  an  ad¬ 
dress  space  and  an  execution  point.  A  process*  address 
space  consists  of  the  set  of  all  memory  locations  accessible 
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by  the  process  during  its  execution.  This  may  be  viewed  as 
a  set  of  procedures  and  data  related  to  the  process.  The 
execution  point  is  defined  by  the  state  of  the  processor  at 
any  given  instant  of  process  execution. 

As  a  logical  entity,  a  process  may  have  logical  attri¬ 
butes  associated  with  it,  such  as  a  security  access  class,  a 
unique  identifier,  and  an  execution  state.  This  notion  of 
logical  attributes  should  not  be  confused  with  the  more  typ¬ 
ical  notion  of  physical  attributes,  such  as  location  in  me¬ 
mory,  page  size,  etc.  In  SASS,  a  process  is  given  a  securi¬ 
ty  access  class,  at  the  time  of  its  creation,  to  specify 
what  authorization  it  possesses  in  terms  of  information  ac¬ 
cess  (to  be  discussed  in  the  next  section)  .  It  is  also  giv¬ 
en  a  unique  identifier  that  provides  for  its  identification 
by  the  system  and  is  utilized  for  interaction  among  process¬ 
es.  A  process  may  exist  in  one  of  three  execution  states: 
1)  running,  2)  ready,  and  3)  blocked.  In  order  to  execute, 
a  process  must  be  mapped  onto  (bound  to)  a  physical  proces¬ 
sor  in  the  system.  Such  a  process  is  said  to  be  in  the 
"running"  state.  A  process  that  is  not  mapped  onto  a  physi¬ 
cal  processor,  but  is  otherwise  ready  to  execute,  is  in  the 
"ready"  state.  A  process  in  the  "blocked"  state  is  waiting 
for  some  event  to  occur  in  the  system  and  cannot  continue 
execution  until  the  event  occurs.  At  that  time,  the  process 
is  placed  into  the  ready  state. 
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B.  INFORMATION  SECURITY 

There  is  an  ever  increasing  demand  for  computer  systems 
that  can  provide  controlled  access  to  the  data  it  stores. 
In  this  thesis,  "information  security"  is  defined  as  the 
process  of  controlling  access  to  information  based  upon 
proper  authorization.  The  critical  need  for  information  se¬ 
curity  should  be  clear.  Banks  and  other  commercial  enter¬ 
prises  risk  the  theft  or  loss  of  funds.  Insurance  and  cre¬ 
dit  companies  are  bound  by  law  to  protect  the  private  or 
otherwise  personal  information  they  maintain  on  their  cus¬ 
tomers.  Universities  and  scientific  institutions  must  pre¬ 
vent  the  unauthorized  use  of  their  often  over-burdened  sys¬ 
tems.  The  Department  of  Defense  and  other  government 
agencies  must  face  the  very  real  possibility  that  classified 
information  is  being  compromised  or  that  weapon  systems  are 
being  tampered  with.  In  fact,  security  related  problems  can 
be  found  at  virtually  every  level  of  computer  usage. 

The  security  of  computer  systems  processing  sensitive 
information  can  be  achieved  by  two  means:  external  security 
controls  and  internal  security  controls.  In  the  first  case, 
security  is  achieved  by  encapsulating  the  computer  and  all 
its  trusted  users  within  a  single  security  perimeter  estab- 
lishe  by  physical  means  (e.g.,  armed  guards,  fences,  etc.) 
This  means  of  security  is  often  undesirable  due  to  its  added 
cost  of  implementation,  the  inherent  risk  of  error-prone  ma¬ 
nual  procedures,  and  the  problem  of  trustworthy  but  error- 
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prone  users.  Also,  since  all  security  controls  are  external 
to  the  computer  system,  the  computer  is  incapable  of  secure¬ 
ly  handling  data  at  differing  security  levels  or  users  with 
differing  degrees  of  authorization.  This  restriction  great¬ 
ly  limits  the  utility  of  modern  computers.  Internal  securi¬ 
ty  controls  rely  upon  the  computer  system  to  internally  dis¬ 
tinguish  between  multiple  levels  of  information 
classification  and  user  authorization.  This  is  clearly  a 
more  desirable  and  flexible  approach  to  information  securi¬ 
ty.  This  does  not  mean,  however,  that  external  security  is 
not  needed.  The  optimal  approach  would  be  to  utilize  inter¬ 
nal  security  controls  to  maintain  information  security  and 
external  security  controls  to  provide  physical  protection  of 
our  system  against  sabotage,  theft,  or  destruction.  The 
primary  concern  of  this  thesis  is  information  security  and 
will  therefore  center  its  discussion  on  the  achievement  of 
information  security  through  implementation  of  the  security 
kernel  concept. 

One  might  argue  that  a  "totally  secure"  computer  system 
is  one  that  allows  no  access  to  its  classified  or  otherwise 
sensitive  information.  Such  a  system  would  not  be  of  much 
value  to  its  users.  Therefore,  when  we  say  that  a  system 
provides  information  security,  it  is  only  secure  with  res¬ 
pect  to  some  specific  external  security  policy  established 
by  laws,  directives,  or  regulations.  There  are  two  distinct 
aspects  of  security  policy:  non-discretion  ary  and  discre- 
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tionary.  Each  user  (subject)  of  the  system  is  given  a  label 
denoting  what  classification  or  level  of  access  the  user  is 
authorized.  Likewise,  all  information  or  segments  (objects) 
within  the  system  are  labelled  with  their  classification  or 
level  of  sensitivity.  The  non-discretionar y  security  me¬ 
chanism  is  responsible  for  comparing  the  authorization  of  a 
subject  with  the  classification  of  an  object  and  determining 
what  access,  if  any,  should  be  granted.  The  DOD  security 
classification  system  provides  an  example  of  the  non-discre- 
tionary  security  policy  and  is  the  policy  implemented  in 
SASS.  The  discretionary  security  policy  is  a  refinement  of 
the  non-discretionary  policy.  As  such,  it  adds  a  higher  de¬ 
gree  of  restriction  by  allowing  a  subject  to  specify  or  res¬ 
trict  who  may  have  access  to  his  files.  It  must  be  empha¬ 
sized  that  the  discretionary  policy  is  contained  within  the 
non-discretionary  policy  and  in  no  way  undermines  or  substi¬ 
tutes  for  it.  This  prevents  a  subject  from  granting  access 
that  would  violate  the  non-discretionary  policy.  An  example 
of  discretionary  security  is  provided  by  the  DOD  "need  to 
know"  policy.  In  SASS,  the  discretionary  policy  is  imple¬ 
mented  within  the  supervisor  [ 9  ]  by  means  of  an  Access  Con¬ 
trol  List  (ACL) .  There  is  an  ACL  maintained  for  every  file 
in  the  system,  which  provides  a  list  of  all  users  authorized 
access  to  that  file.  Every  attempt  by  a  user  to  access  a 
file  is  first  checked  against  the  ACL  and  then  checked 
against  the  non-discretionary  security  policy.  The  "least" 
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or  "most  restrictive"  access  found  in  these  checks  is  then 
granted  to  the  user. 

The  relationship  between  the  labels  associated  with  the 
subject's  access  class  (sac)  and  the  object's  access  class 
(oac)  is  defined  by  a  lattice  model  of  secure  information 
flow  [12]  as  follows  ("  | "  denotes  "no  relationship"): 

1.  sac  =  oac,  read  and  write  access  permitted 

2.  sac  >  oac,  read  access  permitted 

3.  sac  <  oac,  write  access  permitted 

4.  sac  |  oac,  no  access  permitted 

In  order  to  understand  how  these  access  levels  are  deter¬ 
mined,  it  is  necessary  to  gain  an  awareness  of  and  consider¬ 
ation  for  several  basic  security  properties. 

The  "Simple  Security  Property"  deals  with  "read"  access. 
It  states  that  a  subject  may  have  read  access  only  to  those 
object's  whose  classification  is  less  than  or  equal  to  the 
classification  of  the  subject.  This  prevents  a  subject  from 
reading  any  object  possessing  a  classification  higher  than 
his  own. 

The  "Confinement  Property"  (also  known  as  "*-property  ") 
governs  "write"  access.  It  states  that  a  user  may  be  grant¬ 
ed  write  access  only  to  those  objects  whose  classification 
is  greater  than  or  equal  to  the  classification  of  the  sub¬ 
ject.  This  prevents  a  user  from  writing  information  of  a 
higher  classification  (e.g..  Secret)  into  a  file  of  a  lower 
classification  (e.g.,  Unclassified).  It  is  noted  that  while 


this  property  allows  a  user  to  write  into  a  file  possessing 
a  classification  higher  than  his  own,  it  does  not  allow  him 
access  to  any  of  the  data  in  that  file.  The  SASS  design 
does  not  allow  a  user  to  "write  up"  to  higher  classified 
files.  Therefore,  in  SASS,  "sac  <  oac"  denotes  "no  access 
permitted. " 

The  "Compatibility  Property"  deals  with  the  creation  of 
objects  in  a  hierarchical  structure.  In  SASS,  objects  (seg¬ 
ments)  are  hierarchically  organized  in  a  tree  structure. 
This  structure  consists  of  nodes  with  a  root  node  from  which 
the  tree  eminates.  The  Compatibility  Property  states  that 
the  classification  of  objects  must  be  non-decreasing  as  we 
move  down  the  hierarchical  structure.  This  prevents  a  pa¬ 
rent  node  from  creating  a  child  node  of  a  lower  classifica¬ 
tion. 

Several  prerequisites  must  be  met  in  order  to  insure 
that  the  security  kernel  design  provides  a  secure  environ¬ 
ment.  Firstly,  every  attempt  to  access  data  must  invoke  the 
Kernel.  In  addition,  the  Kernel  must  be  isolated  and  tam¬ 
perproof.  Finally,  the  Kernel  design  must  be  verifiable. 
This  implies  that  the  mathematical  model,  upon  which  the 
Kernel  is  based,  must  be  proved  secure  and  that  the  Kernel 
is  shown  is  to  correctly  implement  this  model. 
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c.  segmentation 

Segmentation  is  a  key  element  of  a  security  Kernel  based 
system.  A  segment  can  be  defined  as  a  logical  grouping  of 
information,  such  as  a  procedure,  file  or  data  area  [6]. 
Therefore,  we  can  redefine  a  process'  address  space  as  the 
collection  of  ail  segments  addressable  by  that  process. 
Segmentation  is  the  technique  applied  to  effect  management 
of  those  segments  within  an  address  space.  In  a  segmented 
environment,  all  references  within  an  address  space  require 
two  components:  1)  a  segment  specifier  (number)  and  2)  the 
location  (offset)  within  the  segment. 

A  segment  may  have  several  logical  and  physical  attri¬ 
butes  associated  with  it.  The  logical  attributes  may  in¬ 
clude  the  segment's  classification,  size,  or  permissable  ac¬ 
cess  (read,  write,  or  execute).  These  logical  attributes 
allow  a  segment  to  nicely  fit  the  definition  of  an  object 
within  the  security  kernel  concept,  and  thus  provide  a  means 
for  the  enforcement  of  information  security.  A  segment's 
physical  attributes  include  the  current  location  of  the  seg¬ 
ment,  whether  or  not  the  segment  resides  in  main  memory  or 
secondary  storage,  and  where  the  segment's  attributes  are 
maintained  by  a  segment  descriptor.  The  segment  descriptors 
for  each  segment  in  a  process'  address  space  are  contained 
within  a  Descriptor  Segment  (viz. ,  the  MMU  Image  in  SASS)  to 
facilitate  the  memory  management  of  that  address  space. 
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Segmentation  supports  information  sharing  by  allowing  a 
single  segment  to  exist  in  the  address  spaces  of  multiple 
processes.  This  allows  us  to  forego  the  maintenance  of  mul¬ 
tiple  copies  of  the  same  segment  and  eliminates  the  possi¬ 
bility  of  conflicting  data.  Controlled  access  to  a  segment 
is  also  enforced,  since  each  process  can  have  different  at¬ 
tributes  (read/write)  specified  in  its  segment  descriptor. 
In  the  implementation  of  SASS,  any  segment  which  is  shared, 
but  has  “read  only"  access  by  every  process  sharing  it,  is 
placed  in  the  processor  local  memory  supporting  each  of 
these  processes  rather  than  in  the  global  memory.  This  im¬ 
plies  the  maintenance  of  multiple  copies  of  some  shared  seg¬ 
ments.  It  is  noted  that  the  problem  of  "conflicting  data" 
is  avoided  since  this  only  applies  to  read  only  segments. 
This  apparent  waste  of  memory  and  nonuse  of  existing  sharing 
facilities  is  justified  by  a  design  decision  to  provide  max¬ 
imum  reduction  of  bus  contention  among  processors  accessing 
global  memory.  This  reduction  in  bus  contention  is  consid¬ 
ered  to  be  of  more  importance  than  the  saving  of  memory 
space  provided  by  single  copy  sharing  of  read  only  segments. 
This  decision  is  also  well  supported  by  the  occurrence  of 
decreasing  memory  costs,  which  we  have  experienced  in  terms 
of  high  speed  bus  costs. 
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D.  PROTECTION  domains 

The  requirement  for  isolating  the  Kernel  from  the  re¬ 
mainder  of  the  system  is  achieved  by  dividing  the  address 
space  of  each  process  into  a  set  of  hierarchical  domains  or 
protection  rings  [18].  O'Connell  and  Richardson  [7]  defined 
three  domains  in  the  family  of  secure  operating  systems: 
the  user,  the  supervisor,  and  the  kernel.  Only  two  domains 
are  actually  necessary  in  the  SASS  design  since  it  does  not 
provide  extended  user  applications.  The  Kernel  resides  in 
the  inner  or  most  privileged  domain  and  has  access  to  all 
segments  in  an  address  space.  System  wide  data  bases  are 
also  maintained  within  the  Kernel  domain  to  insure  their  ac¬ 
cessibility  is  only  through  the  Kernel.  The  Supervisor  ex¬ 
ists  in  the  outer  or  least  privileged  domain  where  its  ac¬ 
cess  to  data  or  segments  within  an  address  space  is 
restricted. 

While  protection  domains  may  be  created  through  either 
hardware  or  software  mechanisms,  a  hardware  implementation 
provides  much  greater  efficiency.  Current  microprocessor 
technology  only  provides  for  the  implementation  of  two  do¬ 
mains.  This  two  domain  restriction  does  not  support  O'Con¬ 
nell  and  Richardson's  complete  family  design,  but  it  is  suf¬ 
ficient  to  allow  hardware  implementation  of  the  ring 
structure  required  by  the  SASS  subset. 
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E .  ABSTRACTION 

Dijkstra  [4]  has  shown  that  the  notion  of  abstraction 
can  be  used  to  reduce  the  complexity  of  a  problem  by  apply¬ 
ing  a  general  solution  to  a  number  of  specific  cases.  A 
structure  of  increasing  levels  of  abstraction  provides  a 
powerful  tool  for  the  design  of  complex  systems  and  general¬ 
ly  leads  to  a  better  design  with  greater  clarity  and  fewer 
errors. 

Each  level  of  abstraction  creates  a  virtual  hierarchical 
machine  [6]  which  provides  a  set  of  "extended  instructions" 
to  the  system.  A  virtual  machine  cannot  make  calls  to 
another  virtual  machine  at  a  higher  level  of  abstraction  and 
in  fact  is  unaware  of  its  existence.  This  implies  that  a 
level  of  abstraction  is  independent  of  any  higher  levels. 
This  independence  provides  for  a  loop-free  design.  Addi¬ 
tionally,  a  higher  level  may  only  make  use  of  the  resources 
of  a  lower  level  by  applying  the  extended  instruction  set  of 
the  lower  level  virtual  machine.  Therefore,  once  a  level  of 
abstraction  is  created,  any  higher  level  is  only  interested 
in  the  extended  instruction  set  it  provides  and  is  not  con¬ 
cerned  with  the  details  of  its  implementation.  In  SASS, 
once  a  level  of  abstraction  is  created  for  the  physical  re¬ 
sources  of  the  system,  these  resources  become  "virtualized" 
making  the  higher  levels  of  the  design  independent  of  the 
physical  configuration  of  the  system. 


16 


PAST  B 

SECOBE  ABCHI7AL  STORAGE  SYSTEM  DESIGN 


This  section  is  an  excerpt  from  Implement a t ion  of  Pro 
Management  for  a  Secure  Archival  Storage  System  by  A. 
Strickier  [19].  Minor  changes  have  been  made  for  integra¬ 
tion  into  this  report. 


po  |0) 


Chapter  III 
BASIC  SASS  OVERVIEW 

The  purpose  of  the  Secure  Archival  Storage  System  is  to 
provide  a  secure  "data  warehouse"  or  information  pool  which 
can  be  accessed  and  shared  by  a  variable  set  of  host  compu¬ 
ter  systems  possessing  differing  security  classifications. 
The  primary  goals  of  the  SASS  design  are  to  provide  informa¬ 
tion  security  and  controlled  sharing  of  data  among  system 
users . 

Figure  5  provides  an  example  of  a  possible  SASS  usage. 
The  system  is  used  exclusively  for  managing  an  archival  sto¬ 
rage  system  and  does  not  provide  any  programming  services  to 
its  users.  Thus  the  users  of  the  SASS  may  only  create, 
store,  retrieve,  or  modify  files  within  the  SASS.  The  host 
computers  are  hardwired  to  the  system  via  the  I/O  ports  of 
the  Z8001  with  each  connection  having  a  fixed  security  clas¬ 
sification.  Each  host  must  have  a  separate  connection  for 
each  security  level  it  wishes  to  work  on  (It  is  important  to 
note  that  Figure  5  only  represents  the  logical  interfacing 
of  the  system.  Specifically,  the  actual  connection  with  the 
host  system  must  be  interfaced  with  the  Kernel  as  the  I/O 
instructions  for  the  port  are  privileged)  .  In  our  example. 
Host  #1  can  create  and  modify  only  Top  Secret  files,  but  it 
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can  read  files  which  are  Top  Secret,  Secret,  Confidential, 
or  Unclassi fied.  Likewise,  Host  #2  can  create  or  modify 
secret  files,  using  its  secret  connection  or  confidential 
files,  using  its  confidential  connection.  Host  #2  cannot 
create  or  modify  Top  Secret  or  Unclassified  files. 

In  order  to  provide  information  security  and  controlled 
sharing  of  files,  the  SASS  operates  in  two  domains:  (1)  the 
Supervisor  domain  and  (2)  the  Kernel  domain.  The  SASS  ac¬ 
hieves  this  desired  environment  through  a  distributed  oper¬ 
ating  system  design  which  consists  of  two  primary  modules: 
the  Supervisor  and  the  Security  Kernel.  Each  host  system 
connected  tc  the  SASS  has  associated  with  it  two  processes 
within  the  SASS  which  perform  the  data  transfer  and  file 
management  on  behalf  of  that  host.  The  host  computer  commu¬ 
nicates  directly  with  its  own  I/O  process  and  File  Manager 
process  within  the  SASS. 

We  can  use  our  notion  of  abstraction  to  present  a  system 
overview  of  the  SASS.  The  SASS  consists  of  four  primary 
levels  of  abstraction: 

Level  3-The  Host  Computer  Systems 
Level  2-The  Supervisor 
Level  1-The  Security  Kernel 
Level  O-The  SASS  Hardware 

A  pictorial  representation  of  this  abstract  system  overview 
is  presented  in  Figure  6.  This  representation  is  limited  to 
a  dual  host  system  for  clarity  and  space  restrictions.  Note 
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that  the  Gate  Keeper  module  is  in  actuality  the  logical 
boundary  between  levels  one  and  two  and  as  such  will  be  de¬ 
scribed  separately. 

Level  3,  the  host  computer  systems,  of  SASS  has  already 
been  addressed.  It  should  be  noted  that  the  SASS  design 
makes  no  assumptions  about  the  host  computer  systems.  There¬ 
fore  each  host  may  be  of  a  different  type  or  size  (i.e.-  mi¬ 
cro,  mini,  or  maxi-computer  system) .  Furthermore,  the  ne¬ 
cessary  physical  security  of  the  host  systems  and  their 
respective  data  links  with  the  SASS  is  assumed. 
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Figure  6:  System  Overview  (Dual  Host) 
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Chapter  I¥ 

SOPBHVISOH 

Level  2  of  the  SASS  system  is  composed  of  the  Supervisor 
domain.  As  already  stated,  the  SASS  consists  of  two  do¬ 
mains.  The  actual  implementation  of  these  domains  was 
greatly  simplified  since  the  Z8001  microprocessor  provides 
two  modes  of  execution.  The  system  mode,  with  which  the 
Kernel  was  implemented,  provides  access  to  all  machine  in¬ 
structions  and  all  segments  within  the  system.  The  normal 
mode,  with  which  the  Supervisor  was  implemented,  only  pro¬ 
vides  access  to  a  limited  subset  of  machine  instructions  and 
segments  within  the  system.  Therefore,  the  Supervisor  oper¬ 
ates  in  an  outer  or  less  privileged  domain  than  the  Kernel. 

The  purpose  of  tne  Supervisor  is  to  manage  the  data  link 
between  the  host  computer  systems  and  the  SASS  by  means  of 
Input/Output  control,  and  to  create  and  manage  the  file 
hierarchy  of  each  host  within  the  SASS.  These  functions  are 
accomplished  via  an  Input/Output  (I/O)  process  and  a  Pile 
Manager  (FJ1)  process  within  the  Supervisor.  A  separate  FM 
and  I/O  process  are  created  and  dedicated  to  each  host  at 
the  time  of  system  initialization. 
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A.  PILE  MANAGER  PROCESS 

The  FM  process  directs  the  interaction  between  the  host 
computer  systems  and  the  SASS.  It  interprets  all  commands 
received  from  the  Host  computer  and  performs  the  necessary 
action  upon  them  through  appropriate  calls  to  the  Kernel. 
The  primary  functions  of  the  FM  process  are  the  management 
of  the  Host's  virtual  file  system  and  the  enforcement  of  the 
discretionary  security  policy. 

The  virtual  file  system  of  the  Host  is  viewed  as  a  hier¬ 
archy  of  files  which  are  implemented  in  a  tree  structure. 
The  five  basic  actions  which  may  be  initiated  upon  a  file  at 
this  level  are:  1)  to  create  a  file,  2)  to  delete  a  file,  3) 
to  read  a  file,  4)  to  store  a  file,  and  5)  to  modify  a  file. 
The  FM  process  utilizes  a  FM  Known  Segment  Table  (FM_KST)  as 
the  primary  database  to  aid  in  this  management. 

The  FM  process  maintains  an  Access  Control  List  (ACL) 
through  which  it  enforces  the  discretionary  security  in 
SASS.  The  FM  process  initializes  an  ACL  for  every  file  in 
its  Host's  file  system.  The  ACL  is  merely  a  list  of  all  us¬ 
ers  that  are  authorized  to  access  that  file.  The  ACL  is 
checked  upon  every  attempt  to  access  a  file  to  determine  its 
authorization.  The  user  (host  computer)  directs  the  FM  pro¬ 
cess  as  to  what  entries  or  deletions  should  be  made  in  the 
ACL,  and  as  such,  specifies  who  he  wishes  to  have  access  to 
his  file.  As  noted  earlier,  discretionary  security  is  a  re¬ 
finement  to  the  Non-Discretionary  Security  Policy  and  there- 
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fore  can  only  be  utilized  to  add  further  access  restrictions 
to  those  provided  by  the  Non-Discretionary  Security.  This 
prevents  a  user  from  granting  access  to  a  file  to  someone 
who  otherwise  would  not  be  authorized  access. 

B.  INPOT/OOTPOT  PHOCSSS 

The  I/D  process  is  responsible  for  managing  the  input 
and  output  of  all  data  between  the  host  computer  systems  and 
the  SASS.  The  I/O  process  is  subservient  to  the  FM  process 
and  receives  all  of  its  commands  from  it.  Data  is  transfer¬ 
red  between  the  SASS  and  Host  Computer  systems  in  fixed  size 
"packets".  These  packets  are  broken  up  into  three  basic 
types:  1)  a  synchronization  packet,  2)  a  command  packet,  and 
3)  a  data  packet.  In  order  to  insure  reliable  transmission 
and  receipt  of  packets  between  the  Host  computer  and  the 
SASS,  there  must  exist  a  protocol  between  them.  Parks  [9] 
provides  a  more  detailed  description  of  these  packets,  and  a 
possible  multi-packet  protocol. 
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Chapter  V 
GATE  KEEP  EE 

The  primary  objective  of  the  gate  keeper  is  to  isolate 
the  Kernel  and  make  it  tamperproof.  This  goal  is  accom¬ 
plished  by  reason  of  a  software  ring  crossing  mechanism  pro¬ 
vided  by  the  gate  keeper.  In  terms  of  SASS,  this  notion  of 
"ring-crossing"  is  merely  the  transition  from  the  Supervisor 
domain  to  the  Kernel  domain.  As  noted  earlier,  the  gate 
keeper  establishes  the  logical  boundary  between  the  Supervi¬ 
sor  and  the  Kernel,  and  as  a  matter  of  course,  it  provides  a 
single  software  entry  point  (enforced  by  hardware)  into  the 
Kernel.  Therefore,  any  call  to  the  Kernel  must  first  pass 
through  the  gate  keeper. 

The  gate  keeper  acts  as  a  trap  handler.  Once  it  is  in¬ 
voked  by  a  user  (Supervisor)  process,  the  hardware  preempt 
interrupts  are  masked,  and  the  user  process'  registers  and 
stack  pointer  are  saved  (within  the  kernel  domain) .  It  then 
takes  the  argument  list  provided  by  the  caller  and  validates 
these  passed  parameters  to  insure  their  correctness.  To  aid 
in  the  validation  of  these  parameters,  the  gate  keeper  uti¬ 
lizes  the  Parameter  Table  as  a  database.  The  Parameter  ta¬ 
ble  contains  all  of  the  permitted  functions  provided  by  the 
Kernel.  These  relate  directly  to  the  extended  instruction 
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set  (viz..  Supervisor  calls)  provided  by  the  Kernel  (these 
extended  instructions  will  be  described  in  the  next  sec¬ 
tion)  .  If  an  invalid  call  is  encountered  by  the  gate  keep¬ 
er,  ' an  error  code  is  returned,  and  the  Kernel  is  not  in¬ 
voked.  If  a  valid  call  is  encountered  by  the  gate  keeper, 
the  arguments  and  control  are  passed  to  the  appropriate  Ker¬ 
nel  module. 

Once  the  Kernel  has  completed  its  action  on  the  user  re¬ 
quest,  it  passes  the  necessary  parameters  and  control  back 
to  the  gate  keeper.  At  this  point,  the  gate  keeper  deter¬ 
mines  if  any  software  virtual  preempt  interrupts  have  occur¬ 
red.  If  they  have,  then  the  virtual  preempt  handler  is  in¬ 
voked  vice  the  Kernel  being  exited  (virtual  interrupt 
structure  is  discussed  by  Strickler  [19].  Correspondingly, 
if  a  software  virtual  preempt  has  not  occurred,  then  the  re¬ 
turn  arguments  are  passed  to  the  user  process.  The  user 
process'  registers  and  stack  pointer  (viz.,  its  execution 
point)  are  restored  and  control  returned  to  the  Supervisor 
domain.  A  detailed  description  of  the  Gate  Keeper  interface 
and  implementation  is  provided  by  Strickler  [19]. 
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Chapter  VI 
DISTRIBUTED  KEBNEL 

Level  1  of  our  abstract  view  of  SASS  consists  of  two 
components:  the  distributed  Kernel  and  the  non-distributed 
Kernel.  These  two  elements  comprise  the  Security  Kernel  of 
the  SASS.  The  Security  Kernel  has  two  primary  objectives: 
1)  the  management  of  the  system's  hardware  resources,  and  2) 
the  enforcement  of  the  non-discretionary  security  policy. 
It  executes  in  the  most  privileged  domain  (viz.,  the  system 
mode  of  the  Z8001)  and  has  access  to  all  machine  instruc¬ 
tions.  The  following  section  will  provide  a  brief  descrip¬ 
tion  of  the  distributed  Kernel,  its  components,  and  the  ex¬ 
tended  instruction  set  it  provides.  A  discussion  of  the 
non-distributed  Kernel  will  be  given  in  the  next  section. 

The  distributed  Kernel  consists  of  those  Kernel  modules 
whose  segments  are  contained  (distributed)  in  the  address 
space  of  every  user  (Supervisor)  process.  Thus,  in  effect, 
the  distributed  Kernel  is  shared  by  all  user  processes  in 
the  SASS.  The  distributed  Kernel  is  composed  of  the  Segment 
Manager,  the  Event  Manager,  the  Non-Discret ionary  Security 
Module,  the  Traffic  Controller,  the  Inner  Traffic  Controll¬ 
er,  and  the  Distributed  Memory  Manager  Module.  The  Segment 
Manager  and  the  Event  Manager  are  the  only  "user  visible" 
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modules  in  the  distributed  Kernel.  In  other  words,  the  sat 
of  extended  instructions  available  to  user  processes  invoices 
either  the  Segment  Manager  or  the  Event  Manager. 

A.  SEGMENT  MANAGER 

The  objective  of  the  Segment  Manager  is  the  management 
of  a  process'  segmented  virtual  storage.  The  Segment  Manag¬ 
er  is  invoked  by  calls  from  the  Supervisor  domain  via  the 
gate  keeper.  Calls  to  the  Segment  Manager  are  made  by  means 
of  six  extended  instructions  provided  by  the  segment  manag¬ 
er.  These  extended  instructions  (viz.,  eutry  points)  are: 
1)  CSEATS_S EGMENT ,  2)  D E LET E_SE GHENT,  3)  MAKE_KNOHN,  4) 
TERMINATE,  5)  SM_SWAP_IN,  and  6)  SM_SWAP_OUT.  The  extended 
instructions  CR EATERS EGMENT  and  DELETE_SEGME NT  add  and  re¬ 
move  segments  from  the  SASS.  M AKE_KNOWN  and  TERMINATE  add 
and  remove  segments  from  the  address  space  of  a  process. 
Finally,  SM_SWAP_IN  and  SM_SHAP_OUT  move  segments  from  sec¬ 
ondary  storage  to  main  storage  and  vice  versa. 

The  primary  database  utilized  by  the  Segment  Manager  is 
the  Known  Segment  Table  (KST) .  A  representation  of  the 
structure  of  the  KST  is  provided  in  Figure  7.  The  KST  is  a 
process  local  database  that  contains  an  entry  for  every  seg¬ 
ment  in  the  address  space  of  that  process.  The  KST  is  in¬ 
dexed  by  segment  number  with  each  record  of  the  KST  contain¬ 
ing  descriptive  information  for  a  particular  segment.  The 
KST  provides  a  mapping  mechanism  by  which  the  segment  number 
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of  a  particular  segment  can  be  converted  into  a  unique  han¬ 
dle  for  use  by  the  Memory  Manager.  The  Memory  Manager  will 
be  discussed  in  the  next  chapter. 


30 


- Segment  # 


MM  Handle 


Size 


Acess 

Mode 


In 

Core 


Class 


Mentor  |  Entry 
Seg  No  |  Number 


Figure  7:  Known  Segment  Table  (KST) 
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B.  EVENT  MANAGER 

The  purpose  of  the  Event  Manager  is  the  management  of 
event  data  which  is  associated  with  interprocess  communica¬ 
tions  within  the  SASS.  This  event  data  is  implemented  by 
means  of  eventcounts  (a  synchronization  primitive  discussed 
by  Seed  [11]).  The  Event  Manager  is  invoked,  via  the  Gate 
Keeper,  by  user  processes  residing  in  the  Supervisor  domain. 
There  are  two  eventcounts  associated  with  every  segment  ex¬ 
isting  in  the  Supervisor  domain.  These  eventcounts  (viz.. 
Instance  1  and  Instance  2)  are  maintained  in  a  database  re¬ 
siding  in  the  Memory  Manager.  The  Event  Manager  provides 
its  management  functions  through  its  extended  instruction 
set  READ,  TICKET,  ADVANCE,  and  AWAIT,  and  in  conjunction 
with  the  extended  instructions  TC_ADVANCE  and  TC_AWAIT  pro¬ 
vided  by  the  Traffic  Controller  (to  be  discussed  next) . 
These  extended  instructions  are  based  on  the  mechanism  of 
eventcounts  and  sequencers  [11].  The  Event  Manager  verifies 
the  access  permission  of  every  interprocess  communication 
request  through  the  Non-Discret ionary  Security  Module.  The 
extended  instruction  READ  provides  the  current  value  of  the 
eventcount  requested  by  the  caller.  TICKET  provides  a  com¬ 
plete  time  ordering  of  possibly  concurrent  events  through 
the  mechanism  of  sequencers.  The  Event  Manager  will  be  dis¬ 
cussed  in  more  detail  by  Strickler  [ 19], 
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C.  NON; DISCRETIONARY  SECURITY  NODDLE 

The  purpose  of  the  Non-Discr etionary  Security  Module 
(NDS)  is  the  enforcement  of  the  non-discret ionary  security 
policy  of  the  SASS.  While  the  current  implementation  of 
SASS  represents  the  Department  of  Defense  security  policy, 
any  security  policy  which  may  be  represented  through  a  lat¬ 
tice  structure  [3]  may  also  be  implemented.  The  NDS  is  in¬ 
voked  via  its  extended  instruction  set:  CLASS_EQ  and 
CL ASS_GE .  The  NDS  is  passed  two  classifications  which  it 
compares  and  then  analyzes  their  relationship.  CLASS_3Q 
will  return  a  true  value  to  the  calling  procedure  only  if 
the  two  classifications  passed  were  equal.  The  CLASS_GE  in¬ 
struction  will  return  true  if  a  given  classification  is  ana¬ 
lyzed  to  be  either  greater  than  or  equal  to  another  given 
classification.  The  NDS  does  r.ot  utilize  a  data  base  as  it 
works  only  with  the  parameters  it  is  passed. 

D .  TRAFFIC  CONTROLLER 

The  task  of  processor  scheduling  is  performed  by  the 
traffic:  controller.  Saltzer  [Id]  defines  traffic  controller 
as  the  processor  multiplexing  and  control  communication  sec¬ 
tion  of  an  operating  system.  The  current  SASS  design  uti¬ 
lizes  Reed's  [10]  notion  of  a  two  level  traffic  controller, 
consisting  of:  1)  a  Traffic  Controller  <TC)  and  2)  an  Inner 
Traffic  Controller  (ITC) . 
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The  primary  function  of  the  Traffic  Controller  is  the 
scheduling  (binding)  of  user  processes  onto  virtual  proces¬ 
sors.  A  virtual  processor  (VP)  is  an  abstract  data  struc¬ 
ture  that  simulates  a  physical  processor  through  the  preser¬ 
vation  of  an  executing  process'  attributes  (viz. ,  the 
execution  point  and  address  space).  Multiple  VP's  may  exist 
for  every  physical  processor  in  the  system.  Two  VP's  are 
permanently  bound  to  Kernel  processes  (viz. ,  Memory  Manager 
and  Idle)  and  as  such  are  not  in  contention  for  process 
scheduling.  These  processes  and  their  corresponding  virtual 
processors  are  invisible  to  the  TC.  The  remaining  virtual 
processors  are  either  idle  or  are  temporarily  bound  to  user 
processes  as  scheduled  by  the  TC.  The  database  utilized  by 
the  TC  in  process  scheduling  is  the  Active  Process  Table 
(APT)  .  Figure  8  provides  the  structure  of  the  APT. 

The  APT  is  a  system-wide  Kernel  database  containing  an 
entry  for  every  user  process  in  the  system.  Since  the  cur¬ 
rent  SASS  design  does  not  provide  for  dynamic  process  crea¬ 
tion/deletion,  a  user  process  is  active  for  the  life  of  the 
system.  Therefore#  the  size  of  the  APT  is  fixed  at  the  time 
of  system  generation.  The  APT  is  logically  composed  of 
three  parts:  1)  an  APT  header#  2)  the  main  body  of  the  APT, 
and  3)  a  VP  table.  The  APT  header  includes:  1)  a  Lock  to 
provide  for  a  mutual  exclusion  mechanism,  2)  a  Sunning  List 
indexed  by  VP  ID  to  identify  the  current  process  running  on 
each  VP,  3)  a  Ready  List,  which  points  to  the  linked  list  of 
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processes  which  are  ready  for  scheduling,  and  4)  a  Blocked 
List,  which  points  to  the  linked  list  of  processes  which  are 
in  the  blocked  state  awaiting  the  occurrence  of  some  event. 

A  design  decision  was  made  to  incorporate  a  single  list 
of  blocked  processes  instead  of  the  more  traditional  notion 
of  separate  lists  per  eventcount  because  of  its  simplicity 
and  its  ease  of  implementation.  This  decision  does  not  ap¬ 
preciably  affect  system  performance  or  efficiency  as  the 
"blocked"  list  will  never  be  very  long.  The  VP  table  is  in¬ 
dexed  by  logical  CPU  number  and  specifies  the  number  of  VP's 
associated  with  the  logical  CPU  and  its  first  VP  in  the  Run¬ 
ning  List.  The  logical  CPU  number,  obtained  during  system 
initialization,  provides  a  simple  means  of  uniquely  identif¬ 
ying  each  physical  CPU  in  the  system.  The  main  body  of  the 
APT  contains  the  user  process  data  required  for  its  effi¬ 
cient  control  and  scheduling.  NEXT_AP  provides  the  linked 
list  threading  mechanism  for  process  entries.  The  DBR  entry 
is  a  handle  identifying  the  process'  Descriptor  Segment 
which  is  employed  in  process  switching  and  memory  manage¬ 
ment.  The  ACC ESS_C LASS  entry  provides  every  process  with  a 
security  label  that  is  utilized  by  the  Event  Manager  and  the 
Segment  Manager  in  the  enforcement  of  the  Non-Discretionary 
Security  Policy.  The  PRIORITY  and  STATE  entries  are  the 
primary  data  used  by  the  Traffic  Controller  to  effect  pro¬ 
cess  scheduling.  AFFINITY  identifies  the  logical  CPU  which 
is  associated  with  the  process.  VP  ID  is  utilized  to  iden- 
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tify  the  virtual  processor  that  is  currently  bound  to  the 
process.  Finally,  the  EVENTCOUNT  entries  are  utilized  by 
the  TC  to  manage  processes  which  are  blocked  and  awaiting 
the  occurrence  of  some  event.  HANDLE  identifies  the  segment 
associated  with  the  event,  INSTANCE  specifies  the  event,  and 
COUNT  determines  which  occurrence  of  the  event  is  needed. 

The  Traffic  Controller  determines  the  scheduling  order 
by  process  priority.  Every  process  is  assigned  a  priority 
at  the  time  of  its  creation.  Once  scheduled,  a  process  will 
run  on  its  VP  until  it  either  blocks  itself  or  it  is 
preempted  by  a  higher  priority  process.  To  insure  that  the 
TC  will  always  have  a  process  available  for  scheduling, 
there  logically  exists  an  "idle'*  process  for  every  VP  visi¬ 
ble  to  the  TC.  These  '’idle'1  processes  exist  at  the  lowest 
process  priority  and,  consequently,  are  scheduled  only  if 
there  exists  no  useful  work  to  be  performed. 

The  Traffic  Controller  is  invoked  by  the  occurrence  of  a 
virtual  preempt  interrupt  or  through  its  extended  instruc¬ 
tion  set:  ADVANCE,  AWAIT,  PROCESS_CL ASS,  and 
G ET_DBR_N UMBER.  ADVANCE  and  AWAIT  are  used  to  implement  the 
IPC  mechanism  envoked  by  the  Supervisor.  PROCESS_CLASS  and 
GET_DBR_NUMBER  are  called  by  the  Segment  Manager  to  ascer¬ 
tain  the  security  label  and  DBR  handle,  respectively,  of  a 
named  process.  A  more  detailed  discussion  of  the  TC  is  pro¬ 
vided  by  Strickier  [19]. 
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E.  INKER  TRAPFIC  CONTROLLER 

The  Inner  Traffic  Controller  is  the  second  part  of  our 
two-level  traffic  controller.  Basically,  the  ITC  performs 
two  functions.  It  multiplexes  virtual  processors  onto  the 
actual  physical  processors,  and  it  provides  the  primitives 
for  which  inter-VP  communication  within  the  Kernel  is  imple¬ 
mented.  A  design  choice  was  made  to  provide  each  physical 
processor  in  the  system  with  a  small  fixed  set  of  virtual 
processors.  Two  of  these  VP's  are  permanently  bound  to  the 
Kernel  processes.  The  Memory  Manager  is  bound  to  the  high¬ 
est  priority  VP.  Conversely,  the  Idle  Process  is  bound  to 
the  lowest  priority  VP  and,  as  a  result,  will  only  be  sche¬ 
duled  if  there  exists  no  useful  work  for  the  CPU  to  perform. 
The  primary  database  utilized  by  the  ITC  is  the  Virtual  Pro¬ 
cessor  Table  (VPT) .  Figure  9  illustrates  the  VPT. 

The  VPT  is  a  system  wide  Kernel  database  containing  en¬ 
tries  for  every  CPU  in  the  system.  The  VPT  is  logically 
composed  of  four  parts:  1)  a  header,  2)  a  VP  data  table,  3) 
a  message  table,  and  4)  an  external  VP  list.  The  header  in¬ 
cludes  a  LDCK  (spin  lock)  that  provides  a  mutual  exclusion 
mechanism  for  table  access,  a  RUNNING  LIST  (indexed  by  logi¬ 
cal  CPU  #)  that  identifies  the  VP  currently  running  on  the 
corresponding  physical  CPU,  a  READY  LIST  (indexed  by  logical 
CPU  #)  which  points  to  the  linked  list  of  VP's  which  are  in 
the  "ready"  state  and  awaiting  scheduling  on  that  CPU,  and  a 
FREE  LIST  which  points  to  the  linked  list  of  unused  entries 


38 


Lock 


Running_List  | VPT  Entry  # 


CPU_No — | 


V 


Ready_List  | VPT  Entry  # 

, - 

CPU_No — |  | - 


V 


Free  List 


- VPT 

Header 


VP..ID 


1 

NEXT  | 

1  1  1 

1  1  1 

1  1 

1  1 

1 

J  EXT 

i 

i 

READY | 

DBR |STATE|  IDLE| 

VIRTUALI PHYSICAL  | 

PRI| VP 

|  MSG 

VP  | 

|  | FLAG | 

PREEMPTI  PROCESSOR  | 

1  ID 

|  LIST 

1 

- | 

1 

1 

- j 

1 

_  - 1  -  - 1  -  | 
1  1  1 

---  , - 1 - 1 

1  1  1 

- 1 - 1 - 1 

1  1  1 

1 - 1 - 1 

1  1  i 

1  j 

1  1 

- , - | 

1  1 

- , - , 

1  1 

- , - , 

i  1 

k  i 

■  i  ~ 
i 

— i  — 
i 

_______ 

i 

i 

i 

1 " 

1 

1 - 

1 

, - 

1 

1 - 

[ 

1 

MSS  INDEX 


NEXT  MSG 


SENDER 


MSG 


I 

Message 


I 


List 


EXT  VP  ID - > 

I - - — . . . 

I  VPT  |  |  |  | 

I  Entry |  |  |  | 

I  No  |  |  |  | 

, - - - 


I 


I 

External 


VP 

List 


! 


Figure  9:  Virtual  Processor  Table  (VPT) 
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in  the  message  table.  The  VP  data  table  contains  the  de¬ 
scriptive  data  required  by  the  ITC  to  effectively  manage  the 
virtual  processors.  The  DBR  entry  points  within  the  MMU  Im¬ 
age  to  the  descriptor  segment  for  the  process  currently  run¬ 
ning  on  the  VP.  P8I  (Priority)  ,  STATE,  IDLE_FLAG,  and 
PREEMPT  are  the  primary  data  used  by  the  ITC  for  VP  schedul¬ 
ing.  PREEMPT  indicates  whether  or  not  a  virtual  preempt  is 
pending  for  the  VP.  The  IDLE_F LAG  is  set  whenever  the  TC 
has  bound  an  •'idle'1  process  to  the  VP.  Normally,  a  VP  with 
the  IDLE_FLAG  set  will  not  be  scheduled  by  the  ITC  as  it  has 
no  useful  work  to  perform.  In  fact,  such  a  VP  will  only  be 
scheduled  if  the  PREEMPT  flag  is  set.  This  scheduling  will 
allow  the  VP  to  be  given  (bound)  to  another  process. 
PHYSICAL  PROCESSOR  contains  an  entry  from  the  Processor  Data 
Segment  (PRDS)  that  identifies  the  physical  processor  that 
the  VP  is  executing  on.  EXT_VP_ID  is  the  identifier  by 
which  the  VP  is  known  by  the  Traffic  Controller.  A  design 
choice  was  made  to  have  the  EXT_VP_ID  equate  to  an  offset 
into  the  External  VP  List.  The  External  VP  List  specifies 
the  actual  VP  ID  (viz.,  VPT  entry  number)  for  each  external 
VP  identifier.  This  precluded  the  necessity  for  run  time 
calculation  of  offsets  for  the  EXT_VP_ID.  NEXT_READY_VP 
provides  the  threading  mechanism  for  the  "Ready"  linked 
list,  and  MSG_LIST  points  to  the  first  entry  in  the  Message 
Table  containing  a  message  for  that  VP.  The  Message  Table 
provides  storage  for  the  messages  generated  in  the  course  of 
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Inter-Virtual  Processor  communications.  tlSG  contains  the 
actual  communication  being  passed,  while  SENDER  identifies 
the  VP  which  initiated  the  communication.  NEXT_MSG  provides 
a  threading  mechanism  for  multiple  messages  pending  for  a 
single  VP. 

The  ITC  is  invoked  by  means  of  its  extended  instruction 
set:  WAIT,  SIGNAL,  SWAP_VDBR,  IDLE,  SET_PREEMPT ,  and 
RUNNING_VP.  WAIT  and  SIGNAL  are  the  primitives  employed  in 
implementing  the  Inter-VP  communication.  SWAP_VDBR,  IDLE, 
SET_PREEMPT,  and  RUNNING_VP  are  all  invoiced  by  the  Traffic 
Controller.  SWAP_VDBR  provides  the  means  by  which  a  user 
process  is  temporarily  bound  to  a  virtual  processor.  IDLE 
binds  the  "Idle"  process  to  a  VP  (the  implication  of  this 
instruction  will  be  discussed  later) .  SET_PREEMPT  provides 
the  means  of  indicating  that  a  virtual  preempt  interrupt  is 
pending  on  a  VP  (specified  by  the  TC)  by  setting  the  PREEMPT 
flag  for  that  VP  in  the  VPT.  RUNNING_VP  provides  the  TC 
with  the  external  VP  ID  of  the  virtual  processor  currently 
running  on  the  physical  processor. 

F.  DISTRIBUTED  MEMORY  MANAGER 

The  Distributed  Memory  Manager  provides  an  interface 
structure  between  the  Segment  Manager  and  the  Memory  Manager 
Process.  This  interfacing  is  necessitated  by  the  fact  that 
the  Memory  Manager  Process  does  not  reside  in  the  Distribut¬ 
ed  Kernel  and  consequently  is  not  included  in  the  user  pro- 
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cess *  address  space.  The  primary  functions  performed  in 
this  module  are  the  establishment  of  Inter-VP  Communication 
between  the  VP  bound  to  its  user  process  and  the  VP  perma¬ 
nently  bound  to  the  Memory  Manager  Process,  the  manipulation 
of  event  data,  and  the  dynamic  allocation  of  available  memo¬ 
ry.  The  Distributed  Memory  Manager  Module  is  invoked  by  the 
Segment  Manager  through  its  extended  instruction  sex: 
M M_CR EAT E_ ENTRY ,  MM_DELETE_ENTRY ,  MM_ACTIVATE, 
MM_ DEACTIVATE,  MM_SWAP_IN,  and  MM_SWAP_OUT.  These  extended 
instructions  are  utilized  on  a  one  to  one  basis  by  the  ex¬ 
tended  instruction  set  of  the  Segment  Manager  (e.g., 
5M_SHAP_IN  utilizes  (calls)  MM_SWAP_IN)  .  Wells  [20]  pro¬ 
vides  a  more  detailed  description  of  this  portion  of  the 
Distributed  Memory  Manager  and  the  extended  instruction  set 
associated  with  it. 

The  Distributed  Memory  Manager  is  also  invoked  through 
its  remaining  extended  instructions:  MM_R EAD_EVENTC00NT , 
M M_TICKET,  MM_ADVANCE,  and  MM_ALL0CATE.  These  Distributed 
Memory  Manager  functions  are  discussed  in  detail  by  Strick- 
ler  [  19]. 
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Chapter  711 

NON- DISTRIBUTED  KERNEL 


The  Non-Distributed  Kernel  is  the  second  element  resid¬ 
ing  in  Level  1  of  our  abstract  system  view  of  the  SASS.  The 
sole  component  of  the  Non-Distributed  Kernel  is  the  Memory 
Manager  Process. 

A.  MEMORY  MANAGER  PROCESS 

The  primary  purpose  of  the  Memory  Manager  Process  is  the 
management  of  all  memory  resources  within  the  SASS.  These 
include  the  local  and  global  main  memories,  as  well  as  the 
hard-disic  based  secondary  storage.  A  dedicated  Memory  Man¬ 
ager  Process  exists  for  every  CPU  in  the  system.  Each  CPU 
possesses  a  local  memory  where  process  local  segments  and 
shared,  non-writeable  segments  are  stored.  There  is  aiso  a 
global  memory,  to  which  every  CPU  has  access,  where  the 
shared,  writeable  segments  are  stored.  It  is  necessary  to 
store  these  shared,  writeable  segments  in  the  global  memory 
to  ensure  that  a  current  copy  exists  for  every  access. 

The  Memory  Manager  Process  is  tasked  by  other  processes 
within  the  Kernel  domain  (via  Signal  and  Wait)  to  perform 
memory  management  functions.  These  basic  functions  include 
the  allocatiot/deallocation  of  local  and  global  memory  and 
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and  the  transfer  of  segments  between 


of  secondary  storage, 
the  local  and  global  memory  and  between  secondary  storage 

and  the  main  memories.  The  extended  instruction  set  provid¬ 
ed  by  the  Memory  Manager  Process  includes:  CREATE_ENTRY , 
DELETE.ENTRY,  ACTIVATE,  DEACTIVATE,  SWAP_IN,  and  SWAP_DUT. 
These  instructions  correspond  one  to  one  with  those  of  the 
Distributed  Memory  Manager  Module.  The  system  wide  data 
bases  utilized  by  all  Memory  Manager  Processes  are  the  Glo¬ 
bal  Active  Segment  Table  (G_AST) ,  the  Alias  Table,  the  Disk 
Bit  Map,  and  the  Global  Memory  Bit  Map.  The  processor  local 
databases  used  by  each  Memory  Manager  Process  are  the  Local 
Active  Segment  Table  (L_AST) ,  and  the  Local  Memory  Bit  Map. 
Gary  and  Moore  [5]  provide  a  detailed  description  of  the  Me¬ 
mory  Manager,  its  extended  instruction  set,  and  its  databas¬ 
es. 

A  summary  of  the  extended  instruction  set  created  by  the 
components  of  the  Security  Kernel  is  provided  by  Figure  10. 
One  might  question  the  prudence  of  omitting 
PH YS_PREEMPT_HA NDLER  and  VIRT_PREEMPT_HANDLER  (viz.,  the 
handler  routines  for  physical  and  virtual  interrupts)  from 
the  extended  instruction  set  as  both  cf  these  interrupts  may 
be  raised  (viz. ,  initiated)  from  within  the  Kernel.  A  deci¬ 
sion  was  made  to  not  classify  these  handlers  as  "extended 
instructions"  since  they  are  only  executed  as  the  result  of 
a  physical  or  virtual  interrupt  and  as  such  cannot  be  di¬ 
rectly  invoked  (viz. ,  "called")  by  any  module  in  the  system. 
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A  summary 
presented 


of  the  databases  utilized  by  Kernel  modules  is 
in  Figure  11. 
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Chapter  VIII 
SYSTEM  HARDWARE 


Level  0  of  the  SASS  consists  of  the  system  hardware. 
This  hardware  includes:  1)  the  CPU,  2)  the  local  memory,  3) 
the  global  memory,  4)  the  secondary  storage  (viz.  hard 
disk) ,  and  5)  the  I/O  ports  connecting  the  Host  computer 
systems  to  the  SASS.  Since  the  SASS  design  allows  for  a 
multiprocessor  environment,  there  may  exist  multiple  CPU's 
and  local  memories.  The  target  machine  selected  for  the  in¬ 
itial  implementation  of  the  system  is  the  Zilog  Z8001  micro¬ 
processor  [22].  The  Z8001  is  a  general  purpose  16-bit,  re¬ 
gister  oriented  machine  that  has  sixteen  16-bit  general 
purpose  registers.  It  can  directly  address  8M  bytes  of  me¬ 
mory,  extensible  to  48M  bytes.  The  Z8Q01  architecture  sup¬ 
ports  memory  segmentation  and  two-domain  operations.  The 
memory  segmentation  capability  is  provided  externally  by  the 
Zilog  Z8010  Memory  Management  Unit  (MMU) .  The  Z801Q  MM U 
[23]  provides  management  of  the  Z8001  addressable  memory, 
dynamic  segment  relocation,  and  memory  protection.  Memory 
segments  are  variable  in  size  from  256  bytes  to  64K  bytes 
and  are  identified  by  a  set  of  64  Segment  Descriptor  Regis¬ 
ters,  which  supply  the  information  needed  to  map  logical  me¬ 
mory  addresses  to  physcal  memory  addresses.  Each  of  the  64 
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Descriptor  Registers  contains  a  16-bit  base  address  field, 
an  8-bit  limit  field,  and  an  8-bit  attribute  field.  Unfor¬ 
tunately,  the  Z8001  hardware  was  not  available  for  use  dur¬ 
ing  system  development.  Therefore,  all  work  to  date  has 
been  completed  through  utilization  of  the  Z8002  non-segment- 
ed  version  of  the  Z8000  microprocessor  family  [22].  The  ac¬ 
tual  hardware  used  in  this  implementation  is  the  Advanced 
Micro  Computers  Am96/4116  MonoBoard  Computer  [1]  containing 
the  AmZ8002  sixteen  bit  non-segmented  microprocessor.  This 
computer  provides  32K  bytes  of  on-board  RAM,  8k  bytes  of 
PROM/ROM  space,  two  RS232  serial  I/O  ports,  24  parallel  I/O 
lines,  and  a  standard  INTEL  Multibus  interface.  The  general 
structure  of  the  design  has  been  preserved  by  simulation  of 
the  segmentation  hardware  in  software.  This  software  MMU 
Image  (see  Figure  12)  is  created  as  a  database  within  the 
Inner  Traffic  Controller. 

The  MMU  Image  is  a  processor-local  database  indexed  by 
DBR_No.  Each  DBR_No  represents  one  record  within  the  MMU 
Image.  Each  record  is  an  exact  software  copy  of  the  Segment 
Descriptor  Register  set  in  the  hardware  MMU.  Each  element 
of  this  software  MMU  Image  is  in  the  same  form  utilized  by 
the  special  I/O  instructions  to  load  the  hardware  MMU.  Each 
DBR  record  is  indexed  by  segment  number  (Segment_No) .  Each 
Segment_No  entry  is  composed  of  three  fields:  Base_Addr, 
Limit,  and  Attributes.  Base_Addr  is  a  16-bit  field  which 
contains  the  base  address  of  the  segment  in  physcal  memory. 
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Figure  12:  Memory  Management  Unit  (MM U)  Image 
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Limit  is  an  8-bit  field  that  specifies  the  number  of  conti¬ 
guous  blocks  of  memory  occupied  by  the  segment.  Attributes 
is  an  8-bit  field  representing  the  eight  flags  which  specify 
the  segment's  attributes  (e.g.,  "read",  "execute",  "write", 
etc.)  . 
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Chapter  IX 


SUMMARY 

An  extended  overview  of  the  current  SASS  design  has  been 
presented.  The  four  major  levels  of  abstraction  comprising 
the  SASS  system  have  been  identified,  and  the  major  compo¬ 
nents  of  each  level  have  been  discussed.  The  extended  in¬ 
struction  set  provided  by  the  SASS  Kernel  was  also  defined. 
The  actual  details  of  this  implementation  are  described  by 
Strickler  [19]. 
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PART  C 

THE  DESIGN  AND  IMPLEMENTATION  DF  THE  MEMORY 
MANAGER  FOR  A  SECURE  ARCHIVAL  STORAGE  SYSTEM 


This  section  contains  updated  excerpts  from  a  Naval  Postgra- 
duaduate  School  MS  Thesis  by  E.  E.  Moore  and  A.  V*  Gary  [5]. 
The  origins  of  these  excerpts  are: 

INTRODUCTION  from  Chapter  I 
MEMORY  MANAGER  PROCESS  DETAILED  DESIGN  from  Chapter  III 
STATUS  OF  RESEARCH  from  Chapter  IV 

Minor  changes  have  been  made  for  integration  into  this  report. 


Chapter  X 
IHTBODUCTION 

This  thesis  addresses  the  design  and  partial  implementa¬ 
tion  of  a  memory  manager  for  a  member  of  the  family  of  se¬ 
cure,  distributed,  multi-microprocessor  operating  systems 
designed  by  Bichardson  and  O'Connell  £7].  The  memory  manag¬ 
er  is  responsible  for  the  secure  management  of  the  main  me¬ 
mory  and  secondary  storage.  The  memory  manager  design  was 
approached  and  conducted  with  distributed  processing,  multi¬ 
processing,  configuration  independence,  ease  of  change,  and 
internal  computer  security  as  primary  goals.  The  problems 
faced  in  the  design  were: 

1)  Developing  a  process  which  would  securely  man¬ 
age  files  in  a  multi-processor  environment. 

2)  Ensuring  that  if  secondary  storage  was  inadver¬ 
tantly  damaged,  it  could  usually  be  recreated. 

3)  Minimizing  secondary  storage  accesses. 

4)  Proper  parameter  passing  during  interprocess 
communication . 

5)  Developing  a  process  with  a  loop-free  structure 
which  is  configuration  independent. 
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6)  Designing  databases  which  optimize  the  memory 
management  functions. 

The  proper  design  and  implementation  of  a  memory  manage¬ 
ment  process  is  vital  because  it  serves  as  the  interface 
between  the  physical  storage  of  files  in  a  storage  system 
and  the  logical  hierarchical  file  structure  as  viewed  by  the 
user  (viz.,  the  file  system  supervisor  design  by  Parks  [9]. 
If  the  memory  manager  process  does  not  function  properly, 
the  security  of  that  system  cannot  be  guaranteed. 

The  secure  family  of  operating  systems  designed  by  Rich¬ 
ardson  and  O'Connell  is  composed  of  two  primary  modules,  the 
supervisor  and  the  security  kernel.  A  subset  of  that  system 
was  utilized  in  the  design  of  the  Secure  Archival  Storage 
System  (SASS)  .  The  design  of  the  SASS  supervisor  was  ad¬ 
dressed  by  Parks  [9],  while  the  security  kernel  was  ad¬ 
dressed  concurrently  by  Coleman  [2].  The  SASS  security  ker¬ 
nel  design  is  composed  of  two  parts,  the  distributed  kernel 
and  the  non-distributed  kernel.  The  design  of  the  distribut¬ 
ed  kernel  was  conducted  by  Coleman  [2],  and  processor  man¬ 
agement  was  implemented  by  Reitz  [12].  This  thesis  presents 
the  design  and  implementation  of  the  non-distributed  kernel. 
In  the  SASS  design,  the  non-distributed  kernel  consists 
solely  of  the  memory  manager. 

The  design  of  the  memory  manager  and  its  data  bases  was 
completed.  The  initial  code  was  written  in  PLZ/S'YS,  but 
could  not  be  compiled  due  to  the  lack  of  a  PLZ/SYS  compiler. 
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A  thread  of  the  high  level  code  was  selected,  hand  compiled 
into  PLZ/ASM,  and  run  on  the  Z3000  developmental  module. 


Chapter  XI 

MEMORY  MANAGER  PROCESS  DETAILED  DESIGN 

A .  introduction 

The  memory  manager  is  responsible  for  the  management  of 
both  main  memory  (local  and  global)  and  secondary  storage. 
It  is  a  aon-distributed  portion  of  the  kernel  with  one  memo¬ 
ry  manager  process  existing  per  physical  processor.  The  me¬ 
mory  manager  is  tasked  (via  signal  and  wait)  to  perform  me¬ 
mory  management  functions  on  behalf  of  other  processes  in 
the  system.  The  major  tasks  of  the  memory  manager  are  :  1) 

the  allocation  and  deallocation  of  secondary  storage,  2)  the 
allocation  and  deallocation  of  global  and  local  memory,  3) 
segment  transfer  from  local  to  global  memory  (and  vice  ver¬ 
sa)  ,  and  4)  segment  transfer  from  secondary  storage  to  main 
memory  (and  vice  versa).  There  are  ten  service  calls  (via 
signal)  which  task  the  memory  manager  Process  to  perform 
these  functions.  The  ten  service  calls  are: 

CREATE_ENTRY 

DELSTE_ENTRY 

ACTIVATE 

DEACTIVATE 

SWAP  IN 

SWAPJ3UT 

DEACTIV  ATE_ALL* 

MO  VE_TO_G  LOB AL* 

move_to2local* 

UPDATE* 
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Upon  completion  of  the  service  request,  the  memory  manager 
returns  The  results  of  the  operation  to  the  waiting  process 
(via  signal) .  It  then  blocks  itself  until  it  is  tasked  to 
perform  another  service.  The  hardware  configuration  managed 
by  the  memory  manager  process  is  depicted  in  Figure  13.  The 
shared  data  bases  used  by  all  memory  manager  processes  are 
the  Global  Active  Segment  Table  (G_ASI) ,  the  Alias  Table, 
the  Disk  Bit  Map,  and  the  Global  Memory  Bit  Map.  The  proces¬ 
sor  local  data  bases  used  by  each  process  are  the  Local  Ac¬ 
tive  Segment  Table  (L_AST) ,  the  Memory  Management  Unit  Imag¬ 
es  and  the  Local  Memory  Bit  Map. 


*  In  the  current  state  these  service  calls  are  not  implemente' 
therefore,  there  are  currently  six  service  calls. 
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Figure  13: 


SASS  H/W  System  Overview 
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CONTROL 

SYNCHRONIZATION 


B.  DESIGN  PARAMETERS  AND  DECISIONS 

Several  factors  were  identified  during  the  design  of  the 
memory  manager  process  that  refined  the  initial  kernel  de¬ 
sign  of  Coleman  [2].  The  two  areas  that  were  modified,  were 
the  management  of  the  MMU  images  and  the  management  of  core 
memory.  Both  of  these  functions  were  managed  outside  of  the 
memory  manager  in  the  initial  design.  The  inclusion  of 
these  functions  in  the  memory  manager  process  significantly 
improved  the  logical  structure  of  the  overall  system  de¬ 
sign.  Additional  design  parameters  were  established  to  fa¬ 
cilitate  the  initial  implementation.  These  design  parame¬ 
ters  need  to  be  addressed  before  the  detailed  design  of  the 
memory  manager  process  is  presented. 

It  was  decided  to  make  the  block/page  size  of  both  main 
memory  and  secondary  storage  equal  in  size.  This  was  to  sim¬ 
plify  the  mapping  algorithm  from  secondary  storage  to  main 
memory  (and  vice  versa) .  In  the  initial  design  the  block/ 
page  size  was  set  to  512  bytes. 

The  size  of  the  page  table  for  a  segment  was  set  at  one 
page  (non-paged  page  table) .  This  was  to  simplify  implemen¬ 
tation,  and  had  a  direct  bearing  on  the  maximum  segment  size 
supported  in  the  memory  manager.  For  example,  a  page  size 
cf  256  bytes  will  address  a  maximum  segment  size  of  32,768 
bytes,  while  a  page  size  of  512  bytes  will  address  a  segment 
size  of  131,072  bytes. 


60 


The  size  of  the  alias  table  was  set  to  one  page 
(non-paged  alias  table) .  The  number  of  entries  that  the 
alias  table  will  support  is  limited  by  the  size  of  the  page 
table  (viz. ,  a  page  size  of  512  bytes  will  support  up  to  42 
entries  in  the  Alias  Table)  . 

In  the  original  design,  the  main  memory  allocation  was 
external  to  the  memory  manager.  This  was  due  to  the  parti¬ 
tioned  memory  management  scheme  outlined  by  Parks  [9]  and 
Coleman  [2].  In  the  current  design,  all  address  assignment 
and  segment  transfer  are  managed  by  the  memory  manager.  This 
design  choice  enhanced  the  generality  of  the  design,  and 
provided  support  for  any  memory  management  scheme  (either  in 
the  memory  manager  or  at  a  higher  level  of  abstraction) . 
However,  the  current  design  still  has  a  maximum  core  const¬ 
raint  for  each  process. 

Dynamic  memory  management  is  not  implemented  in  this  de¬ 
sign.  Each  process  is  allocated  a  fixed  size  of  physical 
core.  However,  it  is  not  a  linear  allocation  of  physical 
memory.  The  design  supports  the  maximum  sharing  of  segments 
in  local  and  global  memory.  All  segments  that  are  not 
shared,  or  shared  and  do  not  violate  the  readers/writers 
problem  will  reside  in  local  memory  to  eliminate  the  global 
bus  contention.  The  need  to  compact  the  memory  (because  of 
fragmentation)  should  be  minimal  in  this  design  due  to  the 
maximum  sharing  of  segments.  If  contiguous  memory  is  not 
available,  the  memory  manager  will  compact  main  memory.  Aft¬ 
er  compaction,  the  memory  can  be  allocated. 
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The  design  decision  to  represent  memory  as  one 
contiguous  block  (not  partitioned)  was  made  to  support  a  dy¬ 
namic  memory  management  scheme.  Without  dynamic  memory  man¬ 
agement,  the  process'  total  physical  memory  can  not  exceed 
the  systems  main  memory.  The  supervisor  knows  the  size  of 
the  segments  and  the  size  of  the  process'  virtual  core, 
therefore  it  can  manage  the  swap  in  and  swap  out  to  ensure 
that  the  process'  virtual  core  has  not  been  exceeded. 

In  the  original  design,  the  user's  process  inner-traffic 
controller  maintained  the  software  images  of  the  memory  man¬ 
agement  unit.  This  design  required  the  memory  manager  to  re¬ 
turn  the  appropriate  memory  management  data  (viz. , segment 
location)  to  the  kernel  of  the  user's  process.  In  the  cur¬ 
rent  design,  the  software  images  of  the  MMU  are  maintained 
by  the  memory  manager.  A  descriptor  base  pointer  is  provid¬ 
ed  for  the  inner-traffic  controller  to  multiplex  the  process 
address  spaces.  The  MMU  image  data  base  does  not  need  to  be 
locked  (to  prevent  race  conditions)  due  to  the  fact  that 
process  interrupts  are  masked  in  the  kernel.  Thus,  if  the 
memory  manager  (a  kernel  process)  is  running  then  no  other 
process  can  access  the  MMU  image. 

The  system  initialization  process  has  not  been  addressed 
to  date.  However,  this  design  has  made  some  assumptions 
about  the  initial  state  of  the  system.  Since  the  memory 
manager  handles  the  transfer  of  segments  from  secondary  sto¬ 
rage  to  main  memory,  it  is  likely  to  be  one  of  the  first 
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processes  created.  The  memory  manager's  core  image  will  con¬ 
sist  of  its  pure  code  and  data  sections.  The  minimal  ini¬ 
tialization  of  the  memory  manager's  data  bases  are  entries 
for  the  system  root  and  the  supervisor's  segments  in  the 
G_AST  and  L_AST  (s)  ,  and  the  init ia lizaton  of  the  MMU  images 
with  the  kernel  segments.  The  current  design  does  not  call 
for  an  entry  in  the  G_AST  or  L_AST  for  the  kernel  segments. 
However,  when  system  generation  is  designed  this  will  have 
to  be  readdressed. 

The  original  [2]  memory  manager  databases  have  been  re¬ 
fined  by  this  thesis  to  facilitate  the  memory  management 
functions.  The  major  refinements  of  the  global  and  local  ac¬ 
tive  segment  tables  are  outlined  in  the  following  section. 

C.  DATA  BASES 

1 .  Global  Active  Segment  Table 

The  Global  Active  Segment  Table  (see  Figure  14)  is  a 
system  wide,  shared  data  base  used  by  memory  manager  pro¬ 
cesses  to  manage  all  active  segments.  A  lock/unlock  mechan¬ 
ism  is  utilized  to  prevent  any  race  conditions  from  occur¬ 
ring.  The  signalling  process  locks  the  G_AST  before  it 
signals  the  memory  manager.  This  is  done  to  prevent  a  dead¬ 
ly  embrace  from  occurring  between  memory  manager  processes, 
and  also  to  simplify  synchronization  between  memory  manag¬ 
ers.  The  entire  G_ AST  is  locked  in  this  design  to  simplify 
the  implementation  (vice  locking  each  individual  entry) . 
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Figure  14 


Global  Active  Segment  Table 


The  G_A  ST  size  is  fixed  at  compile  time.  The  size  of 
the  G_AST  is  the  product  of  the  G_AST  record  size,  the  maxi¬ 
mum  number  of  processes  and  the  number  of  authorized  known 
segments  per  process.  Although  the  G_ASI  is  of  fixed  size, 
it  is  plausible  to  dynamically  manage  the  entries  as  pro¬ 
posed  by  Richardson  and  O'Connell  [7].  The  current  memory 
manager  design  could  be  extended  to  include  this  dynamic 
management. 

The  Unique_Id  field  is  a  unique  segment  identification 
number  in  the  G_AST.  This  field  is  four  bytes  wide  and  will 
provide  over  four  billion  identification  numbers.  A  design 
choice  was  made  not  to  manage  the  reallocation  of  the  uni- 
que_id's.  Thus  when  a  segment  is  deleted  from  the  system, 
the  unique_id  is  not  reused. 

The  Global_Address  field  is  used  to  indicate  if  a  seg¬ 
ment  resides  in  global  or  local  memory.  If  not  null,  it  con¬ 
tains  the  global  memory  base  address  of  a  segment.  A  null 
entry  indicates  that  the  segment  might  be  in  local  memo¬ 
ry  (s)  . 

The  Pr ocessors_L_ASTE_#  field  is  used  as  a  connected 
processors  list.  The  field  is  an  array  structure,  indexed 
by  Processor_Id .  It  identifies  which  L_AST  the  segment  is 
active  in,  and  provides  the  index  into  each  of  these  tables. 
The  design  choice  of  maintaining  an  entry  in  the  L_AST  for 
all  locally  active  segments  implies  that  if  all  entries  in 
the  Processors_L_AST E_#  field  are  null,  the  segment  is  not 
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active  and  can  be  removed  from  the  G_AST  (viz.,  no  proces¬ 
sors  are  connected) . 

The  Flag_Bits  field  consists  of  the  written  bit,  and 
the  writable  bit.  The  written  bit  is  set  when  a  segment  is 
swapped  out  of  memory,  and  the  MMU  image  indicates  that  it 
has  been  written  into.  The  writable  bit  is  set  during  seg¬ 
ment  loading  to  indicate  that  some  process  has  write  access 
to  that  segment. 

If  an  active  segment  is  a  leaf,  the  G_ASTE_#_Parent 
field  provides  a  back  pointer  to  the  G_ASI  index  of  its  pa¬ 
rent.  This  back  pointer  to  the  parent  is  important  during 
the  creation  of  a  segment.  If  a  reguest  is  received  to 
create  a  segment  which  has  a  leaf  segment  as  its  parent, 
then  an  alias  table  has  to  be  created  for  that  parent. 
Also,  the  alias  table  of  the  parent's  parent  needs  to  be  up- 
dared  to  reflect  the  existence  of  the  newly  created  alias 
table  (see  Figure  15).  The  indirect  pointer  shown  is  the 
back  pointer  to  the  parent  via  the  G_ASI. 

The  No_Acti ve_In_Memory  field  is  a  count  of  the  number 
of  processes  that  have  the  segment  in  global  memory.  It  is 
used  during  swap  out  to  determine  if  the  segment  can  be  re¬ 
moved  from  global  memory. 

The  No_Active_Depenaents  field  is  a  count  of  the  number 
of  active  leaf  segments  that  are  dependent  on  this  entry 
(viz.,  require  that  this  segment  remain  in  the  G_AST)  .  Each 
time  a  process  activates  or  deactivates  a  dependent  segment 
this  field  is  incremented  or  decremented. 
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Figure  15:  Alias  Table  Creation 


67 


The  Size  field  is  the  size  of  the  segment  in  bytes.  The 
p age_Table_loca tion  field  is  the  disk  location  of  the  page 
table  for  a  segment,  and  the  Alias_Table_Location  field  is 
the  disk  location  of  the  alias  table  for  the  segment.  The 
Alias_Table  field  can  be  null  to  indicate  that  no  alias  ta¬ 
ble  exists  for  the  segment. 

The  last  three  fields  are  used  in  the  management  of  ev- 
entcounts  and  sequencers  [ 12],  The  Sequencer  field  is  used 
to  issue  a  service  number  for  a  segment.  The  Instance_1 
field  and  Instance_2  field  are  eventcounts  (i.e.,  are  used 
to  indicate  the  next  number  of  occurances  of  some  event) . 

2.  Local  Active  Segment  Table 

The  Local  Active  Segment  Table  (see  Figure  16)  is  a 
processor  local  data  base.  The  L_AST  contains  the  character¬ 
istics  (viz.,  segment  number,  access)  of  each  locally  active 
segment.  An  entry  exists  for  each  segment  that  is  active  in 
a  process  '•loaded'*  on  this  CPU  and  in  local  memory.  The 
first  field  of  the  L_AST  contains  the  memory  address  of  the 
segment.  If  the  segment  is  not  in  memory,  this  field  is 
used  to  indicate  whether  the  L_AST  entry  is  available  or  ac¬ 
tive.  The  Segment_No/Access  field  is  a  combination  of  seg¬ 
ment  number  and  authorized  access.  It  is  an  array  of  records 
data  structure  that  is  indexed  by  DBB_# .  The  first  record 
element  (viz. , most  significant  bit)  is  used  to  indicate  the 
access  (read  or  read/write)  permitted  to  that  segment.  The 
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second  record  element  (viz.,  the  next  seven  bits)  is  used  to 
indicate  the  segment  number.  A  null  segment  number  indi¬ 
cates  that  the  process  does  not  have  the  segment  active. 

Index  # 


Memory 

Segment_#/Access_Auth 

Addr 

DBH_0 

DBB_  1 

DBR_2 

DBR_  3 

DBR_4 

DBR_5 

Figure  16:  Local  Active  Segment  Table 
3-  Alias  Table 

The  alias  table  (see  Figure  17)  is  a  memory  manager  data 
base  which  is  associated  with  each  non  leaf  segment  in  the 
kernel.  An  aliasing  scheme  is  used  to  prevent  passing  sys¬ 
temwide  information  (unigue_id.)  out  of  the  kernel.  Seg¬ 
ments  can  only  be  created  through  a  mentor  segment  and  entry 
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number  into  the  mentor's  alias  table.  When  a  segment  is 
created,  an  entry  must  be  made  in  its  mentor  segment's  alias 
table.  Thus  the  mentor  segment  must  be  known  before  that 
segment  can  be  created. 


Entry_# 


Unique _ID 


Size 


Class 


Page  Table  |  Alias  Table 
Location  |  Location 


I 


Figure  17:  Alias  Table 

The  alias  table  consists  of  a  header  and  an  array  struc¬ 
ture  of  entries.  The  header  has  two  "pointers"  (viz.,  disk 
addresses) ,  one  that  links  the  alias  table  to  its  associated 
segment  and  one  that  links  the  alias  table  to  the  mentor 
segment's  alias  table.  The  header  is  provided  to  support  the 
re-construction  of  the  file  system  after  a  system  crash  due 


70 


to  device  I/O  errors.  It  is  not  used  at  all  during  normal 
operations.  Each  entry  in  the  array  structure  consists  of 
five  fields  for  identifying  the  created  segments.  The  Uni- 
que_Id  field  contains  the  unique  identification  number  for 
the  segment.  The  Size  field  is  used  to  record  the  size  of 
the  segment.  The  Class  field  contains  the  appropriate  secur¬ 
ity  access  class  of  the  segment.  The  Page_Table_Location 
field  has  the  disk  address  of  the  page  table.  A  null  entry 
indicates  a  zero-length  segment.  The  Alias_Table_Locat ion 
field  has  the  disk  address  of  the  alias  table  for  the  seg¬ 
ment.  A  null  entry  indicates  that  the  segment  is  a  leaf 
segment. 

4 .  Memory  Management  Unit  Image 

The  Memory  Management  Unit  Image  (MMU^lmage)  is  a  pro¬ 
cessor  local  data  base.  It  is  an  array  structure  that  is  in¬ 
dexed  by  the  DBR_#.  Each  MMU_Image  (see  Figure  18)  includes 
a  software  representation  of  the  segment  descriptor  regis¬ 
ters  (SDR)  for  the  hardware  MMU  [23].  This  is  in  exactly 
the  format  used  by  the  special  I/O  instructions  for  loading/ 
unloading  the  MMU  hardware.  The  SDR  contains  the 
Base_Address,  Limit  and  Attribute  fields  for  each  loaded 
segment  in  the  process'  address  space.  The  Base_Address 
field  contains  the  base  address  of  the  segments  in  memory 
(local  or  global) .  The  Limit  field  is  the  number  of  blocks 
of  contiguous  storage  for  each  segment  (zero  indicates  one 
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block) .  The  Attribute  field  contains  eight  flags.  Five 
flags  are  used  for  protecting  the  segment  against  certaii 
types  of  access,  two  encode  the  type  of  accesses  made  to  the 
segment  (read/write)  ,  and  one  indicates  the  special  struc¬ 
ture  of  the  segment  [23],  Five  of  the  eight  flags  in  the. 
attribute  field  are  used  by  the  memory  manager.  The  "systet 
only”  and  "execute  only”  flags  are  used  to  protect  the  code 
of  the  kernel  from  malicious  or  unintentional  modifications. 
The  "read  only"  flag  is  used  to  control  the  read  or  write 
access  to  a  segment.  The  "change"  flag  is  used  to  indicate 
that  the  segment  has  been  written  into,  and  the  "CPU-inhi-; 
bit"  flag  is  used  to  indicate  that  the  segment  is  not  in  me¬ 
mory. 

The  last  two  fields  of  the  MM(J_Image  are  the  Block_Usec 
field  and  the  Maximum_Available_Blocks  field.  These  twc 
fields  are  used  in  the  mangement  of  each  process'  virtual 
core  and  are  not  associated  with  the  hardware  HMU. 
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Figure  18:  Memory  Management  Unit  Image 
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5.  Memory  All oca tion/Deallo cation  Bit  Mags 

All  of  the  memory  allocation/deallocatioa  bit  maps  (see 
Figure  19)  are  basically  the  same  structure.  Secondary  sto¬ 
rage,  global  memory  and  local  memory  are  managed  by  memory 
bit  maps.  The  Disk_Bit_Map  is  a  global  resource  that  is 
protected  from  race  conditions  via  the  locking  convention 
for  the  G_AST.  Each  bit  in  the  bit  map  is  associated  with  a 
block  of  secondary  storage.  A  zero  indicates  a  free  block 
of  storage  while  a  one  indicates  an  allocated  block  of  sto¬ 
rage.  The  Global_Memory_Bit_Map  is  used  to  manage  global  me¬ 
mory.  It  is  a  shared  resource  that  is  protected  from  race 
conditions  by  the  locking  of  the  G_AST.  The  Lo- 
cal_Memory_Bit_Map  is  the  same  structure  as  the  Glo- 
bal_Memory_Bit_Map  and  is  used  to  manage  local  memory.  The 
Local_Hemor y_Bit_Map  is  not  locked  since  it  is  not  a  shared 
resource  between  memory  managers. 


74 


Memory  Bit  Map 

222222222 

Page  012345678911111  ....  444555555 

01234  789012345 


Figure  19:  Memory  Allocation/Deallocation  Map 

D .  BASIC  FUNCTIONS 

The  detailed  source  code  for  the  basic  functions  and 
main  line  of  the  memory  manager  is  presented  in  Appendix  J. 

In  the  discussion  of  the  memory  manager  design,  a  pseu¬ 
do-code  similar  to  PLZ/SYS  is  utilized.  The  rationale  for 
using  this  pseudo-code  was  to  provide  a  summary  of  the  memo¬ 
ry  manager  source  code,  and  to  facilitate  the  presentation 
of  this  design. 

It  is  assumed  that  the  memory  manager  is  initialized 
into  the  ready  state  at  system  generation  (as  previously 
mentioned) .  When  the  memory  manager  is  initially  placed 
into  the  running  state,  it  will  block  itself  (via  a  call  to 
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the  kernel  primitive  Wait) .  Wait  will  return  a  message  from 
a  signalling  process.  This  message  is  interpreted  by  the  me¬ 
mory  manager  to  determine  the  requested  function  and  its  re¬ 
quired  arguments.  The  function  code  is  used  to  enter  a  case 
statement,  which  directs  the  request  to  the  appropriate  me¬ 
mory  manager  procedure. 

When  the  requested  action  is  completed,  the  memory  man¬ 
ager  returns  a  success  code  (and  any  additional  required 
data)  to  the  signalling  process  via  a  call  to  the  kernel 
primitive  Signal.  This  call  will  awaken  the  process  which 
requested  the  action  to  be  taken,  and  place  the  returned 
message  into  that  process*  message  queue.  When  that  action 
is  completed,  the  memory  manager  will  return  to  the  top  of 
the  loop  structure  and  block  itself  to  wait  for  the  the  next 
request.  The  main  line  pseudo-code  of  the  memory  manager 
process  is  displayed  in  Figure  20. 
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ENTRY 

INITIALIZE_PROCESSOR_LOCAL_ VARIABLES 
DO 

!  CHECK_IF_MSG_QUEUE_EMPTY  ! 

VP_ID ,  MSG  :=  WAIT 

FUNCTION,  ARGUMENTS  :=  VALI DATE_MSG  (MSG) 

IF  FUNCTION 

CASE  CREATS_ENTRY  THEN 

SUCCESS_CODE  :=  CREATE  ENTRY  (ARGUMENTS) 
CASE  DELETS_ENTRY  THEN 

SUCC ESS_CODE  :=  DELETE  ENTRY  (ARGUMENTS) 
CASE  ACTIVATE  THEN 

SUCCESS_CODE  :=  ACTIVATE  (ARGUMENTS) 

CASE  DEACTIVATE  THEN 

SUCCESS_CODE  :=  DEACTIVATE  (ARGUMENTS) 

CASE  SWAP_IN  THEN 

SUCCESS_CODE  :=  SWAP_IN  (ARGUMENTS) 

CASE  SWAP_OUT  THEN 

SUCC  ESS_CODE  :=  SWAP_OUT  (ARGUMENTS) 

CASE  DEACTIVATE_ALL  THEN 

SUCCESS_CODE  :=  DEACTIVATE_ALL  (ARGUMENTS) 
CASE  MOVE_TO_GLOBAL  THEN 

SUCCESS_CODE  :=  MOV E _TO_GLOBAL  (ARGUMENTS) 
CASE  MO VE_TO_ LOCAL  THEN 

SUCCESS_CODE  :=  MOVE_TO_LOCAL  (ARGUMENTS) 
CASE  UPDATE  THEN 

SUCCESS_CODE  :  =  UPDATE  (ARGUMENTS) 

FI 

SIGNAL  (VP_I  D ,  SUCCESS_CODE ,  ARGUMENTS) 

OD 

END  MEMORY_MANAGER_PLZ/SYS  MODULE 


Figure  20:  Memory  Manager  Mainline  Code 
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1 •  Create  an  Alias  Table  Entry 

Create_Entry  is  invoked  when  a  user  desires  to  create  a 
segment.  A  segment  is  created  by  allocating  secondary  sto¬ 
rage,  and  by  making  an  entry  (unigue_id,  secondary  storage 
location,  size,  classification)  into  it's  mentor  segment's 
alias  table.  This  implies  that  the  mentor  segment  must  have 
an  alias  table  associated  with  it,  and  that  the  mentor  seg¬ 
ment  must  be  active  in  order  to  obtain  the  secondary  storage 
location  of  the  alias  table. 

The  mentor  segment  can  be  in  one  of  two  states.  It  may 
have  children  (viz.,  have  an  alias  table),  or  it  may  be  a 
leaf  segment  (viz.,  not  have  an  alias  table).  If  the  mentor 
segment  has  children,  it  has  an  alias  table  and  this  alias 
table  can  be  read  into  core,  secondary  storage  can  be  allo¬ 
cated,  and  the  data  can  be  entered  into  the  alias  table.  If 
the  mentor  segment  is  a  leaf,  an  alias  table  must  be  created 
for  that  segment  before  it  (the  alias  table)  can  be  read 
into  core  and  data  entered  into  it  (see  Figure  15) . 

The  pseudo-code  for  CREATE_ENTRY  PROCEDURE  is  presented 
in  Figure  21.  The  arguments  passed  to  Create_Entry  are  the 
index  into  the  G_AST  for  the  mentor  segment,  the  entry  num¬ 
ber  into  its  alias  table,  the  size  of  the  segment  to  be 
created,  and  the  security  access  class  of  that  segment.  The 
return  parameter  is  a  success  code,  which  would  be 
" seg_created"  for  a  successful  segment  creation. 
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CREAI E_ENTRY  PROCEDURE  (PAR_INDEX  WORD,  ENTR  Y_#  WORD, 

SIZE  WORD,  CLASS  BYTE) 

RETURNS  (SUCCESS_CODE  BYTE) 

LOCAL  3LKS  WORD,  PAGE_TABLE_LOC  WORD 
ENTRY 

IF  ALIAS_TABLE_DOES_NOT_EXIST  THEN 
5UCCESS_CODE  :=  CRE ATE_ ALIAS _T ABLE 
IF  SUCCES S_CODE  <>  VALID  THEN  RETURN 
FI 
FI 

BLKS  :=  CALCULATE_N0_3LKS_REQ  (SIZE) 

SUCCESS_CODE  :=  R  EAD_ ALIAS _T ABLE  ( 

G_AST[  PAR~INDEX  ].  ALIAS_TABLE_LOC) 

IF  SUCCESS_CODE  <>  VALID  THEN  RETURN 
FI 

SUCCESS _CODE  :=  CHECK_DUP_ENTR Y  !  in  alias  table  ! 

IF  SUCCES  S_CODE  <>  VALID  THEN  RETURN 

FI 

SUCCESS_CODE ,  PAG E_TABLE_LOC  :=  ALLOC_SEC_ STORAGE  (BLKS) 
IF  SUCCESS_CODE  <>  VALID  THEN  RETURN 

FI 

UPDATE_ALIAS_TABLE  (ENTRY_# ,  SIZE,  CLASS,  P AGE_TABLE_LOC) 
SUCCESS.CODE  :=  W RITE_ALIAS_TA BLE  ( 

G_AST[  ?AR_INDEX  ].  ALI  AS  JTABLE_LOC) 
IF  SUCCE SS_CODE  <>  VALID  THEN  RETURN 
ELSE  SUCcisS_CODE  :=  SEG_CREATED 
FI 

END  CREATE  ENTRY 


Figure  21 


Create  Entry  Pseudo-code 


When  invoked,  Create_Entry  will  determine  which  state 
the  mentor  segment  is  in  (viz.,  if  it  has  an  alias  table). 
If  an  alias  table  does  not  exist  for  the  mentor  segment,  one 
is  created  and  the  alias  table  of  the  mentor  segment’s  pa¬ 
rent  is  updated.  The  alias  table  is  read  into  core  and  a 
duplicate  entry  check  is  made.  If  no  duplicate  entry  exists, 
the  segment  size  is  converted  from  bytes  to  blocks,  and  the 
secondary  storage  is  allocated  for  non-zero  sized  segments. 
The  appropriate  data  is  entered  into  the  alias  table  and  the 
alias  table  is  then  written  back  to  secondary  storage. 

2.  Delete  an  Alias  Table  Entry 

Delete_Entry  is  invoked  when  a  user  desires  to  delete  a 
segment.  A  segment  is  deleted  by  deallocating  secondary 
storage,  and  by  removing  the  appropriate  entry  from  the  ali¬ 
as  table  of  its  mentor  segment  (the  reverse  logic  of 
Create_Entry) .  This  implies  that  the  mentor  segment  must  be 
active  at  the  time  of  deletion.  There  are  three  conditions 
that  can  be  encountered  during  the  deletion  of  a  segment: 
the  segment  to  be  deleted  may  be  an  inactive  leaf  segment, 
an  active  leaf  segment,  or  a  mentor  segment. 

If  the  segment  to  be  deleted  is  an  inactive  leaf  segment 
(viz.,  has  been  swapped  out  of  core,  and  does  not  have  an 
entry  in  the  G_AST) ,  the  secondary  storage  can  be  deallocat¬ 
ed  and  the  entry  deleted  from  the  mentor  segment’s  alias  ta¬ 
ble.  If  the  segment  is  an  active  leaf  segment,  the  segment 
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must  first  be  swapped  out  of  core  and  deactivated  before  it 
can  be  deleted.  This  entails  signalling  the  memory  manager 
of  each  processor,  in  which  the  segment  is  active,  to  swap 
out  and  deactivate  the  segment. 

If  the  segment  to  be  deleted  is  a  mentor  segment,  an 
alias  table  exists  for  that  segment  .  If  the  alias  table  is 
empty,  the  secondary  storage  for  the  alias  table  and  the 
segment  can  be  deallocated,  and  the  entry  for  the  deleted 
segment  can  be  removed  from  its  mentor’s  alias  table.  If  the 
alias  table  contains  any  entries,  the  segment  cannot  be  de¬ 
leted  because  these  entries  would  be  lost.  If  this  condition 
is  encountered  a  success  code  of  "leaf_segment_exists"  is 
returned  to  the  process  which  requested  to  delete  the  entry. 
Due  to  a  confinement  problem  in  "upgraded"  segments,  this 
Success_code  cannot  always  be  passed  outside  of  the  kernel. 
This  implies  that  the  segment  manager  must  strictly  prohibit 
deletion  of  a  segment  with  an  access  class  not  equal  to  that 
of  the  process. 

The  pseudo-code  for  DELETE_ENTBY_PBOCEDUBE  is  presented 
in  Figure  22.  The  parameters  that  are  passed  to  this  proce¬ 
dure  are  the  parent's  index  into  the  G_AST  and  the  entry 
number  into  the  parent's  alias  table  of  the  segment  to  be 
deleted.  The  alias_table_loc  field  is  checked  to  determine 
the  state  of  the  mentor  segment  (either  a  leaf  or  a  node) , 
and  the  appropriate  action  is  then  taken.  A  success  code  is 
returned  to  indicate  the  results  of  this  procedure. 
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D ELETE_ENTR Y  PROCEDURE  (  P AR_INDEX  WORD,  ENTRY_#  WORD  ) 
RETURNS  (SUCCESS_CODE  BYTE) 

LOCAL  P AR_INDEX  WORD 
ENTRY 

!  ChecJc  if  the  passed  mentor  segment  has  an  alias  table. 
IF  G  AST[  PAR_INDEX  ].  ALIAS  TABLE_LOC  <>  NULL 
SUCCESS_CODE  :=  READ_ALIAS_TABLE  ( 

G_AST[  PAR_INDEX].ALI  AS_TAB LE_LOC) 

ELSE 

SUCCESS_CODE  :=  NO_CHI LD_TO_DELETE 
FI 

IF  SUCCESS_CODE  <>  VALID  THEN  RETURN 

FI 

!  Determine  if  segment  has  children  in  alias  table  ! 

IF  ALI AS_TABLE_NOT_EMPTY  THEN 

SUCCESS_CODE  :=  LEAF_SEG  HE  NT_EXISTS 
RETURN  !  Deletion  will  delete  children  ! 

ELSE 

!  Search  G  AST  with  UNIQUE_ID  to  verify  segment  inactive 
IF  ~ACTIVE_IN_G_AST  THEN 

!  Check  if  active  in  AST  ! 

IF  ACTIVE_IN_L_AST  THEN 

DEACTIVATE_ALL  {G_ AS T_INDEX ,  L_AST_INDEX) 
FI 

!  Check  G_AST  to  verify  segment  inactive  in  other  L_AST's 
IF  ACT  IV  E_IN_OTHER_L_ AS  T  THEN 

SIGNAL_TO_DEACTI VATE_ALL  (G  AST  INDEX) 

FI 

FI 

FREE_SEC_STOR  AGE_OF_SEG_&_ALIAS_IF_EXISTS 
DELETE_ALI AS_TABLE_ENTRY 
FI 

DELETE_ALIAS_TABLE_ENTRY 
SUCCESS_CODE  :=  W RITE_ALIAS_TABL E  ( 

G_AST[ PAR_INDEX]. ALIAS  TABLE_LOC) 

IF  SUCCESS_CODE  =  VALID  THEN 

SUCCESS_CODE  :=  SEG_D  ELETED 
FI 

END  DELETE  ENTRY 


Figure  22:  Delete  Entry  Pseudo-code 


82 


3.  Activate  a  Segment 

Activate  is  invoked  when  a  user  desires  to  make  a  seg¬ 
ment  known  by  adding  a  segment  to  his  address  space.  A  seg¬ 
ment  is  activated  by  making  an  entry  into  the  L_AST  for  that 
processor,  and  the  G_AST.  The  activated  segment  could  be  in 
one  of  three  states;  it  could  have  previously  been  activated 
by  another  process  and  have  a  current  entry  in  both  the 
G_AST  and  L_AST,  it  could  have  previously  been  activated  by 
another  process  on  a  different  processor  and  have  an  entry 
in  the  G_AST  but  not  the  L_AST,  or  it  could  be  inactive  and 
have  an  entry  in  neither  the  G_AST  nor  the  L_AST. 

If  the  segment  to  be  activated  already  has  entries  in 
both  the  L_ AST  and  G_AST,  these  entries  need  only  be  updated 
to  indicate  that  another  process  has  activated  the  segment. 
The  segment  number  is  entered  into  the  Seg- 
ment_No/Access_Auth  field  of  the  L_AST,  and  if  the  segment 
is  a  leaf,  its  mentor's  No_Active_Dependents  field  in  the 
G_AST  is  incremented.  In  this  design,  the  G_ASI  is  always 
searched  to  determine  if  the  segment  has  been  previously  ac¬ 
tivated  by  another  process. 

If  the  segment  to  be  activated  has  an  entry  in  the  G_AST 
but  not  the  L_AST,  an  entry  must  be  made  in  the  L_AST  and 
the  G_AST  must  be  updated.  The  L_AST  is  searched  to  deter¬ 
mine  an  available  index.  The  segment  number  is  entered  into 
the  L_AST,  and  the  index  number  is  entered  into  the  G_AST 
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Processors_L_ASTE_#  field.  If  the  segment  to  be  activated  is 
a  leaf  segment,  its  mentor's  No_Active_Dependents  field  in 
the  G_AST  is  incremented. 

If  the  activated  segment  does  not  have  an  entry  in  eith¬ 
er  the  G_AST  or  L_AST,  an  entry  must  be  made  in  both.  The 
G_AST  is  searched  to  find  an  available  index,  and  the  entry 
is  made.  The  L_AST  is  then  searched  to  find  an  available  in¬ 
dex,  and  the  entry  is  made.  The  L_AST  index  is  then  entered 
into  the  G_ AST  Processors_L_ASTE_#  field.  If  the  activated 
segment  is  a  leaf,  the  No_Acti ve_Dependents  field  of  its 
mentor's  G_ AST  entry  is  incremented. 

The  pseudo-code  for  ACTIVATE  PROCEDURE  is  presented  in 
Figure  23.  The  parameters  that  are  passed  are  the  DBR_#  of 
the  signalling  process,  the  mentor  segment's  index  into  the 
G_ AST ,  the  alias  table  entry  number,  and  the  segment  number 
of  the  activated  segment.  The  mentor  segment  is  always 
checked  to  determine  if  it  has  an  associated  alias  table.  If 
if  does  not,  the  success  code  of  "alias_does_not_exist"  is 
returned.  If  the  alias  table  does  exist,  it  is  read  into 
core  and  the  entry  number  is  used  as  an  index  to  obtain  the 
activated  segment's  unigue_id.  The  G_ASI  is  then  searched 
to  determine  if  the  segment  has  already  been  activated.  If 
the  unique_id  is  found,  the  G_AST  is  updated  and  the  L_AST 
is  either  updated  or  an  entry  is  made  (depending  on  whether 
an  entry  existed  or  not) .  If  the  unigue_id  of  the  segment 
was  not  found  during  the  search  of  the  G_AST,  an  entry  must 
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be  made  in  both  the  G_AST  and  L_AST.  Activate  returns  the 
activated  segment's  classification,  size,  and  handle  to  the 
signalling  process. 
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ACTIVATE  PROCEDURE  (DBR_#  BYTE,  PAR_INDEX  WORD, 

ENTR Y_#  WORD,  SEGMENT_NO  BYTE) 
RETURNS  (SUCCESS_CODE  BYTE,  RET_G_AST_HA NDLE  HANDLE, 

CLASS  BYTE,  SIZE  WORD) 

LOCAL  G_I ND  EX  WORD,  L_INDEX  WORD 
ENTRY 

!  Verify  that  passed  segment  is  a  mentor  segment  I 
IF  G_AST[  PAR^INDEX  ].  ALIAS _TABL£_LOC  <>  0  THEN 
SUCCESS_CODE  :=  READ_ALIAS_TABLE  ( 

G_AST[ PAR_INDEX ]. ALIAS_TABLE_LOC) 

ELSE 

SUCCESS_CODE  :=  ALIAS_DOES_NOT_EXIST 
FI 

IF  SUCCESS_CODE  <>  VALID  THEN  RETURN 
FI 

!  Check  3 _AST  to  determine  if  active  ! 

SUCCESSICODE, INDEX  :=  SEARCH_G_AST  (UNIQUE_ID) 

IF  SUCCESS_CODE  =  FOUND  THEN~ 

IF  SEGMENT_IN_L_AST  THEN 

UPD ATE_L_AST~  (SEGHENT_NO) 

ELSE 

HAKE_L_AST_ENTRY  (DBR_# ,  SEGHENT_NO) 

UPD ATE_G_AST  (L_INDExT 

IF  G_AST[INDEX  ]7ALIAS_TABLE_LOC  =  NULL  THEN 

G  AST[  PAR  INDEX].  NO  DEPENDENTS  ACTIVE  +=  1 
FI 
FI 

ELSE 

MAKE_G_AST_ENTRY  (ENTEY_#) 

MAK E_L  AST_E NTRY  (PAR  INDEX,  ENTRY  #) 

FI 

SUCCESS_CODE  :=  SEG_ACTIV AT  ED 
END  ACTIVATE 


Figure  23:  Activate  Pseudo-code 
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Deacti vate  a  Segment 

Deactivate  is  invoiced  when  a  user  desires  to  remove  a 
segment  from  his  address  space.  To  deactivate  a  segment, 
the  memory  manager  either  removes  or  updates  an  entry  in 
both  the  L_AST  and  G_AST.  Deactivate  uses  the  reverse  logic 
of  activate.  Once  a  segment  is  deactivated,  it  can  only  be 
reactivated  via  its  mentor's  alias  table  as  discussed  in  ac¬ 
tivate.  If  a  process  requests  to  deactivate  a  segment  which 
has  not  been  swapped  out  of  the  process'  virtual  core,  the 
memory  manager  swaps  the  segment  out  and  updates  the  MMU  im¬ 
age  before  the  segment  is  deactivated.  The  segment  to  be 
deactivated  could  be  in  one  of  three  states;  more  than  one 
process  could  concurrently  hold  the  segment  active  in  the 
L_AST,  the  segment  could  be  held  active  by  one  process  in 
the  L_AST  and  more  than  one  in  the  G_AST,  the  segment  could 
be  held  active  by  only  one  process  in  both  the  L_AST  and  the 
G_AST . 

Deactivation  of  leaf  segments  and  mentor  segments  are 
handled  differently.  If  the  segment  is  a  mentor  segment  and 
has  active  dependents,  it  cannot  be  removed  from  the  G_AST 
(even  though  no  process  currently  has  that  segment  active) . 
This  is  based  on  the  design  decision  which  requires  that  the 
mentor  of  all  active  leaf  segments  remain  in  the  G_AST  to 
allow  access  to  its  alias  table.  The  mentor's  alias  table 
must  be  accessible  when  an  alias  table  is  created  for  a  de- 
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pendent  leaf  segment.  If  a  leaf  segment  is  deactivated,  the 
No_ Active_Depen dents  field  of  its  mentor's  G_AST  entry  is 
decremented.  A  mentor  segment  can  only  be  removed  from  the 
G_ AST  if  no  process  holds  it  active,  and  it  has  no  active 
dependents. 

If  more  than  one  process  concurrently  hold  a  segment  ac¬ 
tive  in  the  L_AST ,  and  one  of  them  signals  to  deactivate 
that  segment,  the  entry  in  the  L_AST  is  updated.  This  is  ac¬ 
complished  by  nulling  out  the  Segment_No/Access_Auth  field 
of  the  L_AST  for  the  appropriate  process.  If  required,  the 
No_Active_Dependents  field  of  its  mentor  segment*  s  G^AST  en¬ 
try  is  decremented. 

If  only  one  process  holds  the  segment  active  in  the 
L_AST,  and  that  Process  signals  to  deactivate  the  segment, 
the  L_ASI  entry  for  that  segment  is  removed.  The  Proces- 
sors_L_ASTE_#  is  updated  and  checked  to  determine  if  there 
are  other  connected  processors.  If  there  are  no  other  con¬ 
nected  processors  and  the  segment  has  no  active  dependents, 
the  segment  is  removed  from  the  G_AST.  If  there  are  other 
connected  processors,  the  G_AST  is  updated.  If  the  deacti¬ 
vated  segment  is  a  leaf,  the  mentor  segment's 
No_Active_Dependents  field  in  the  G_AST  is  decremented. 

The  pseudo-code  for  DEACTIVATE  PROCEDCJRE  is  presented  in 
Figure  24.  The  parameters  that  are  passed  to  the  memory  man¬ 
ager  are  the  DBR_#  of  the  signalling  process,  and  the  index 
into  the  G_AST  for  the  segment  to  be  deactivated.  The 
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and  then  removes  the  en- 


procedure  first  updates  the  L_AST , 
try  if  no  local  process  holds  the  segment  active.  The  G_AST 
is  then  updated,  and  its  mentor  segment  is  checked  (if  the 
deactivated  segment  was  a  leaf) ,  to  determine  if  it  can  be 
removed.  If  no  processes  currently  hold  the  segment  active, 
and  it  has  no  active  dependents,  the  segment  is  removed  from 
the  G  AST. 
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DEACTIVATE  PROCEDURE  { DBR_#  BYTE,  PAR_INDEX  WORD) 
RETURNS  (SUCCESS_CODE  BYTE) 

LOCAL  INDEX  WORD 
ENTRY 

!  Check  if  segment  is  in  core  ! 

IF  3_AST[ INDEX  ]. NO_ACTIVE_IN_MEMORY  <>  0  THEN 

!  Check  MM U  image  to  determine  if  in  local  memory 
IF  I N_LOCAL_MEMOR Y  THEN 

SUCCESS_CODE  :=  OUT  ( DBR_#,  INDEX) 

FI 

FI 

!  Remove  process  segment_no  entry  in  L_AST  ! 

L_AST[  L_INDEX ]. SEGMENT_NO/ACCESS_AUIH[ DBR_# ]  =  0 
CHECK_IF_ACTIVE_IN_L_AST  (L_AST_INDEX) 

if  n5t_active  IN_L_AST  THEN 

L_AST[L  INDEX*]*  ME(10RY_ADDR  :=  AVAILABLE 
FI 

!  Check  if  deleted  segment  was  a  leaf  i 
IF  G  AST[ INDEX ]. G_ASTE  #  PAR  <>  0  THEN 

G_AST[PAR_INDEX].NO_DEPENDENTS_ACTIVE  -=  1 
!  Determine  if  parent  can  be  removed  ! 

CHECK_FOR_RE  MOV  AL  (PAR_IN  DEX) 

FI 

!  Determine  if  deactivated  segment  can  be  removed  ! 
CHECK_FOR_REMOVAL  (INDEX) 

SUCCESS _CODE  :=  SSG_DEACTI V ATED 
END  DEACTIVATE 


Figure  24:  Deactivate  Pseudo-code 
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5 


Swag  a  Segment  In 

SWAP_IN  is  invoked  when  a  user  desires  to  swap  a  seg¬ 
ment  into  main  memory  (global  or  local)  from  secondary  sto¬ 
rage.  A  segment  is  swapped  into  main  memory  by  obtaining  the 
secondary  storage  location  of  its  page  table  from  the  G_AST, 
allocating  the  required  amount  of  main  memory,  and  reading 
the  segment  into  the  allocated  main  memory.  The  segment  must 
be  active  before  it  can  be  swapped  into  core,  and  the  re¬ 
quired  main  memory  space  must  be  available.  Three  conditions 
can  be  encountered  during  the  invocation  of  SWAP_IN.  The 
segment  can  already  be  located  in  global  memory,  the  segment 
can  already  be  located  in  one  or  more  local  memories,  or  the 
segment  may  only  reside  in  secondary  storage. 

If  the  segment  is  not  in  local  or  global  memory,  local 
memory  is  allocated,  the  segment  is  read  into  the  allocated 
memory,  and  the  appropriate  entries  are  made  in  the  UflU  im¬ 
age,  the  L_AST  and  the  G_AST.  If  the  segment  is  already  in 
global  memory,  it  can  be  assumed  that  the  segment  is  shared 
and  writable.  In  this  case  the  only  required  actions  are  to 
update  the  G_AST  and  L_AST.  The  No_Active_In_Jlemory  field  or 
the  G_ASI  entry  is  incremented,  and  the  JIMU  image  is  updated 
to  reflect  the  swapped  in  segment's  core  address  and  attri¬ 
butes  . 

If  the  segment  already  resides  in  one  or  more  local  me¬ 
mories,  it  must  be  determined  if  the  segment  is  "shared"  and 
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" writable" .  A  segment  is  "shared"  if  it  exists  in  more  than 
one  local  memory.  A  segment  is  "writable"  if  one  process  has 
write  access  to  that  segment.  If  the  segment  is  not  shared 
or  not  writable  and  in  local  memory,  the  appropriate  entries 
are  updated  in  the  i!M0  image,  the  L_AST,  and  the  G_AST.  If 
the  segment  does  not  reside  in  local  memory,  the  required 
amount  of  local  memory  is  allocated,  the  segment  is  read 
into  the  allocated  memory,  and  the  appropriate  entries  are 
made  in  the  MMO  image,  the  L_AST,  and  the  G_AST. 

If  the  segment  is  shared,  writable,  and  in  local  memory, 
the  segment  must  be  moved  to  global  memory.  If  the  segment 
is  not  in  the  memory  manager's  local  memory,  it  signals 
another  memory  manager  to  move  the  segment  to  global  memory. . 
After  the  segment  is  moved  to  global  memory,  the  memory  man¬ 
ager  signals  all  of  the  connected  memory  manager's  to  update 
their  L_AST  and  MMU  data  bases.  When  all  local  data  bases 
are  current,  the  memory  manager  updates  the  G_ AST  and  re¬ 
turns  a  success  code  of  seg_activat ed . 

The  pseudo-code  for  SWAP_IN  PROCEDURE  is  presented  in 
Figure  25.  The  arguments  passed  to  SWAP_IN  are  the 
G_AST_INDEX  of  the  segment  to  be  moved  in,  the  process' 
DBR_# ,  and  the  access  authorized.  SWAP_IN  will  convert  the 
segment  size  from  bytes  to  blocks,  and  verify  that  the  pro¬ 
cess'  core  will  not  be  exceeded.  If  the  virtual  core  will 
be  exceeded,  a  success  code  of  "core_space_exceeded"  will  be 
returned.  If  write  access  is  permitted,  the  writable  bit  is 


92 


set 


Checks  are  then  performed  to  determine  the  segment's 


storage 
tion  is 


location  (local  or  global),  and  the  appropriate  ac- 
taken . 
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S  W  AP_IN  PROCEDURE  (INDEX  WORD,  DBR_#  BITE, 

ACCESS_AUTH  BYTE) 

RETURNS  (SUCCESS_CODE  BYTE) 

LOCAL  L_INDEX  WORD,  BLKS  WORD 
ENTRY 

BLKS  :=  CALCULATE_NO.  _OF_BLKS  (G_AST[  INDEX  ].  SIZE) 

S  UCCESS_CODE  :=  CHECK_HAX_LINEAR_CORE  (BLKS) 

IF  SUCCESS_CODE  =  VI RTUAL_LI NE AR_CORE_FULL  THEN 
RETURN 
FI 

G_AST[  INDEX  ].  NO_SEGMENTS_IN_HEHOR Y  ♦=  1 

IF  ACCESS_AUTH  =  WRITE”  THEN 

G  AST[INDEX].FLAG  BITS  :=  WRITABLE_BI T_SET 
FI 

I  Determine  if  segment  can  be  put  in  local  memory  ! 

IF  G_AST[  INDEX  ].  FLAG_BITS  AND  WRITABLE_HASK  =0 
ORIF  3_AST[  INDEX  ].  NO_ACTI VE_IN_NEMOR Y  <=  1  THEN 
!  Determine  if  already  in  local  memory  ! 
CHECK_LOCAL_MEHORY  (L_AST_I NDEX) 

IF  NOT_I N_LOCAL_M  EMORY  THEN 

ALLOC ATE_LOCAL_MEMQRY  (BLKS) 

READ_SEG  MENT  *(PAGE_T ABLE_L0C,  BASE  A  DDR) 

L_AST[ L_INDEX]  :=  BASE  ADDR 
FI 

ELSE 

IF  NOT_I N_G  LO B A L_ MEMORY  THEN 
UPDATE_MMU 
UPD ATE_L_AST 
RETURN 

ELSE 

ALLOCATE_GLOBAL_HEMORY  (BLKS) 

IF  I N_LOCAL_ MEMORY  THEN 

MOVE_TO_GLOBAL  (L_INDEX,  BASE_ADDR ,  SIZE) 

ELSE 

SIGNAL  OTHER_HEHORY_MANAGERS (INDEX, BASE_ADDR) 
FI 
FI 
FI 

UPDATE_MMU_IMAGE  (DBR_# ,SEG_# , B ASE_AD DR , ACCES S , BLKS) 
UPDATE_L_AST_ACCESS  (L_INDEX, ACCESS , DBR_# ) 

SUCCESS_CODE  :=  SWAPPED_IN 
END  SWAP  IN 


Figure  25:  Swap_In  Pseudo-code 
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6 


Swag  a  Segment  Out 

SWAP_0tJT  is  invoked  when  a  user  desires  to  move  a  seg¬ 
ment  out  of  core.  A  segment  is  swapped  out  of  core  by  ob¬ 
taining  its  secondary  storage  location,  writing  the  segment 
to  that  location  (if  required)  ,  and  deallocating  the  main 
memory  used.  The  decision  to  write  the  segment  is  deter¬ 
mined  by  the  G_AST  written  bit.  This  bit  is  set  whenever  the 
segment  has  been  modified.  The  segment  to  be  swapped  out 
can  be  in  one  of  two  states:  the  segment  can  be  in  local 
memory,  or  the  segment  can  be  in  global  memory. 

If  one  process  has  the  segment  in  local  memory  and  the 
written  bit  is  set,  the  segment  is  written  into  secondary 
storage  and  the  local  memory  is  deallocated.  If  the  written 
bit  is  not  set,  the  local  memory  need  only  be  deallocated. 
If  more  than  one  process  has  the  segment  in  the  same  local 
memory,  the  segment  remains  in  core.  The  appropriate  aMU  im¬ 
age  is  updated  to  reflect  the  segments  deletion  and  the 
G_AST  No_Active_In_Hemory  field  is  decremented. 

All  segments  in  global  memory  are  shared  and  writable. 
If  a  process  requests  the  segment  to  be  swapped  out,  the 
segment  remains  in  memory.  The  aMU  image  is  updated  to  re¬ 
flect  the  segment's  deletion,  and  the  G_AST 
No_Active_In_aemory  field  is  decremented.  If  the 
No_Active_In_aemory  indicates  that  one  process  has  the  seg¬ 
ment  in  core,  its  memory  manager  is  signalled  to  move  the 
segment  to  local  memory. 
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The  pseudo-code  for  SWAP_OUT  PROCEDURE  is  presented  in 
Figure  26.  The  arguments  passed  to  SWAP_OUT  are  the  DBR_# 
of  the  signalling  process,  and  the  G_AST_INDEX  of  the  seg¬ 
ment  to  be  removed.  The  return  parameter  is  a  success  code. 
SWAP_OUT  removes  the  segment  from  the  process's  virtual 
core,  deletes  the  segment  from  its  HMU  image,  and  decrements 
the  No_Acti ve_In_Memory  field.  If  the  segment  can  be  removed 
from  memory,  it  is  determined  which  memory  can  be  deallocat¬ 


ed.  If  the  segment  has  been  modified,  it  is  written  back  to 
secondary  storage  and  the  appropriate  memory  deallocated. 
If  the  segment  has  not  been  modified,  the  appropriate  memory 
is  deallocated.  If  after  the  deletion  one  process  has  the 
segment  in  global  memory,  its  memory  manager  need  only  be 
signalled  to  move  the  segment  to  local  memory.  When 
S W AP_OUT  successfully  completes,  it  returns  a  success  code 
of  "swapped  out". 


it  returns  a  success  code 


SWAP_OUT  PROCEDURE  (DBR_#  BYTE,  INDEX  WORD) 

RETURNS  (SUCCESS_CODE  BYTE) 

ENTRY 

BLKS  :=  G_AST[  INDEX  ]. SIZE  /  BLK_SIZE 
FREE_PROCESS_LINEAR_CORE  (BLKS)  " 

DEL ETE_MMU_ ENTRY  (DBR_  It ,  SEG_*) 

G_AST[  INDEX  ].  NO_SEGMENTS_IN_MEMORY  -  =  1 

!  Determine  if  segment  has  been  written  into  ! 

IF  MMU_IMAGE[  DBR_#  ].  SDR(  SEG_#  ].  ATTRIBUTES3 WRITTEN  THEN 
!  If  segment  has  been  written  into,  update  G_AST  ! 

G _A ST [INDEX]. FLAG_BITS  :=  WRITTEN 
FI 

!  Determine  if  segment  is  in  global  memory  I 
IF  G_AST[ INDEX  ]. GLOB AL_ADDR  <>  NULL  THEN 

IF  G_AST[  INDEX  ].NO_SEGMENTS_IN_MEMORY  =  0 
ANDIF  G_AST[ INDEX  ].FLAG_BITS  =~WRITTEN  THEN 
WRITE_SEG  (PAGE_TABLE_LOC,  MEMORY_ADDR) 
FREE_LOCAL_BIT_MAP  (MEMORY_ADDR , BLKS) 

ELSE 

IF  G_AST[ INDEX  ] . NO_ACTI VE_IN_MEMO RY  =  0  THEN 
FREE_LOCAL_BITlMAP  (MEMORY  ADDR, BLKS) 

FI 

FI 

ELSE  i  If  not  in  global  memory  ! 

IF  G_AST[  INDEX].  NO_ACTIVE_IN_MEMORY  =  0 
ANDIF  G_AST[ INDEX  ].FLAG_BITS  =  WRITTEN  THEN 
WRITE_SEG  (PAGE_TABLE_LOC,  GLOBAL_ADDR) 
FREE_GLOBAL_BIT_MAP  ( GLOB AL_ADDR ,  BLKS) 

ELSE 

IF  G  AST[INDEX  ].  NO_ACTIVE_IN_MEMORY  =  0  THEN 
FREE_GLOBAL_BIT_MA?  (GLOBAL_ADDR,  BLKS) 

FI 

FI 

FI 

SUCCESS_CODE  :=  SWAPPED_OUT 
END  SWAP  OUT 


Figure  26:  Swap_Out  Pseudo-code 


7. 


Deactivate  All  Segments 

DEACTIV  ATE_ALL  is  invoked  when  it  becomes  necessary  to 
remove  a  segment  from  every  process'  address  space.  Each 
process  is  checked  to  determine  if  the  segment  is  active.  If 
a  process  has  the  segment  active,  it  is  deactivated  from  its 
address  space.  The  pseudo  code  for  Deactivat e_all  is  illus¬ 
trated  in  Figure  27.  The  parameters  passed  to  Deacti- 
vate_all  are  the  deactivated  segment's  G_AST  index  and  the 
L_AST  index.  The  L_AST  is  searched  by  DBR_#  to  determine 
which  process  has  the  segment  active.  If  the  check  reveals 
that  the  segment  is  active,  it  is  deactivated  by  calling 
Deactivate.  If  the  segment  was  successfully  deactivated  from 
all  processes,  a  success_code  of  valid  is  returned. 
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DEACTIVATE_ALL  PROCEDURE  (INDEX  WORD,  L_INDE  X  WORD) 
RETURNS  (SUCCESS_CODE  BYTE) 

ENTRY 

LOCAL  I  BYTE 
I  :=  0 
DO 

IP  I  =  MAX  DBR  #  THEN 
EXIT 
PI 

IF  L_AST[  L_INDEX].  SEGMENT  NO/ACCESS  AUTH[  I  ] 
<>  ZERO  THEN 

SUCCESS_CODE  :=  DEACTIVATE  (I,  INDEX) 

IF  SUCCESS_CODE  <>  SEG  DEACTIVATED  THEN 
RETURN 
FI 
FI 

I  ♦=  1 
OD 

SUCCES  S_CODE  :=  VALID 
END  DEACTIV ATE~ALL 


Figure  27:  Deactivate  All  Pseudo-code 

8.  Wove  a  Segment  to  Global  Memory 

MOVE_TO_GLOBAL  is  invoked  when  it  becomes  necessary  to 
move  a  segment  from  local  to  global  memory.  If  a  segment  re¬ 
sides  in  one  or  more  local  memories,  and  a  process  with 
write  access  swaps  that  segment  into  core,  or  if  a  segment 
resides  in  in  local  memory  (with  write  access)  and  another 
process  with  read  access  requests  the  segment  swapped  in, 
the  segment  is  moved  from  a  local  to  global  memory  to  avoid 
a  secondary  storage  access.  If  the  segment  resides  in  the 
running  memory  manager's  local  memory,  it  will  affect  the 
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segment  transfer,  otherwise  it  will  signal  another  memory 
manager  of  a  connected  processor  to  affect  the  transfer. 
Figure  28  illustrates  the  pseudo-code  for  MOVE_tTO_GLOBAL. 
Once  the  segment  has  been  moved  to  global  memory,  the  sig¬ 
nalled  memory  manager  will  update  the  MMU  images  for  all 
connected  processes,  and  deallocate  the  freed  local  memory. 
A  success  code  of  completed  will  be  returned  to  the  signall¬ 
ing  memory  manager.  The  parameters  passed  to  the  memory 
manager  are  the  segment's  L_AST  index  the  global  memory  ad¬ 
dress  of  the  move,  and  the  size  of  the  segment.  This  infor- 
mation  is  passed  because  the  G_AST  is  locked  during  this  re¬ 
quest  . 


M0VE_T0_3L0BAL  PROCEDURE  ( L_I NDEX  WORD,  GLOB AL_A DDR  WORD, 

SIZE  WORD) 

RETURNS  (SUCCESS_CODE  BYTE) 

ENTRY 

!  Move  segment  from  local  memory  to  global  memory  l 
D0_MEM0 R Y  MOVE  ( MEMORY_ADDR ,  GLOBAL_ADDR) 

L_AST[  INDEX  ].  MEMORY_ADDR  :=  AVAILABLE 
!  Update  the  MMU  image  to  reflect  new  address  ! 

DO  FOR_ALL_DBR* S 

IF  L_AST[ L_ INDEX]. SEGME NT_N O/ACCESS _AUTH  <>  0  ANDIF 
MMU_I MAGE[ DBR_#  ]. SDR[ SEG_#].ATTRIBUTES  =  IN_ LOCAL  THEN 
MMU_IMAGE[  DBR_#  ].S DR[  SEG  #].BASE  ADDR  :  =GLOBAL_ADDR 
PI 
OD 

SUCCESS _CODE  :=  VALID 
END  MOVE  TO  GLOBAL 


Figure  28:  Move  To  Global  Pseudo-code 
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9. 


a~-  1  **um  is  local  ai33a 

i107u__io_loc AL  is  invoiced  when  it  h 

t  becomes  necessary  to 

”°Ve  a  Seg0ent  f“»  global  to  local  memory  ^ls  o 
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y  are  the  segment's  L  AST 

th9  3l0M1  a ddress  of  the  seg.eat,  asd  the  sij  of 
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3LKS  :=  SIZE  /  3LK_SIZ2 
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PI  L  ^  50«[  S2G__#  ].  3 AS ADDS  ;=BASE  ADDS2SS 

OD 

own  S0CC2ss_COP2  :=  VALID 
-NO  ;10V2_T0_  LOCAL 


Figure  29  : 


dove  To  Local  Pseudo-code 
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10.  Update  the  MHO  Image 


UPDATE  is  invoiced  following  a  MO VE_T0_GL0BAL  operation. 
After  a  segment  has  been  moved  from  local  memory  to  global 
memory,  it  is  necessary  to  signal  the  memory  managers  of  all 

i 

connected  processors  to  update  their  MHO  images  and  L_AST 
with  the  current  location  of  the  segment.  They  must  also 
deallocate  the  moved  segment's  local  memory.  Figure  30  il¬ 
lustrates  the  pseudo-code  of  UPDATE «  The  parameters  passed 
to  the  memory  manager  are  the  segment's  L_ASI  index,  the  new 
global  address  for  the  segment,  and  the  size  of  the  segment. 
The  return  parameter  is  a  success  code. 


UPDATE  PROCEDURE  (L_INDEX  WORD,  GLOBAL  ADDR  WORD, 

SIZE  WORD) 

RETURNS  (SUCCESS  CODE  BITE) 

ENTRY 

DO  F0R-ALL_DBR«  S 

IP  L_AST["l_INDEX  ]. SEGMENT  NO/ACCESS  AUTH  <>  0  ANDIF 
SMU_I MAGE[ DBR_#  ]. SDR( SEG  * ] . ATT2I3UTES  =  IN  LOCAL  THEN 
MMU_IM  AGE(  DBR_t  ].  SDRf  SEG_#  ].BASE_ADDR  7* 

GLOBAL  ADDR 
FI 
0D 

BLKS  :=  SIZE  /  BLK_SIZE 
FREE_LOCAL_BIT_MAP  (MEMORY  ADDR, BLKS) 

L_AST[ L_INDEX ]. MEMO RY_ ADD R~:=  ACTIVE 
SUCCESS  CODE  :=  VALID* 

END  UPDATE 


Figure  30:  Update  Pseudo-code 
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E. 


SUMMARY 


In  this  chapter  the  derailed  design  of  the  memory  manag¬ 
er  process  has  been  presented.  The  purpose  of  the  memory 
manager  was  outlined,  followed  by  a  detailed  discussion  of 
the  memory  manager's  data  bases.  The  design  presented  has 
identified  ten  basic  functions  for  the  memory  manager.  The 
success  codes  returned  by  the  memory  manager  are  presented 
in  Figure  31. 

This  design  has  assumed  that  the  kernel  level  inter-pro¬ 
cess  synchronization  primitives  will  be  Saltzer's  signal  and 
wait  primitives  [14],  This  fact  dominated  the  design  deci¬ 
sion  to  lock  the  G_ AST  in  the  user's  process  before  it  sig¬ 
nals  the  memory  manager.  In  a  multi-processor  environment, 
the  possibility  of  a  deadly  embrace  exists  if  the  memory 
manager  processes  lock  the  G_AST.  Should  follow  on  work  im¬ 
plement  eventcounts  and  sequencers  as  kernel  level  synchron¬ 
ization  primitives,  the  locking  of  the  G_AST  and  memory  man¬ 
ager  synchronization  will  need  to  be  readdressed. 


SYSTEM  WIDE 

INVALID 
SWAPPED_IN 
S  W  APPED~0  (JT 
SEG_ACTI VATED 
S  EG_DEACTIV  AT  ED 
SEG_CREATED 
S  EG_DELETED 
VIRTUAL_CORE_FULL 
D U PLICA TE_E NT RY 
RE AD_ERROR 
WRITE_ERROR 
DRIVE  NOT  READY 


MEMORY  MANAGER  LOCAL 

VALID 
INVALID 
FOUND 
NOT_FOUND 
IN_LOCAL_MEMORY 
NOT_I N_LOCA  L_MEMO  RY 
!  ♦  DISK  ERRORS  ! 


KERNEL  LOCAL 
LEAF_SEGMENT_EX ISTS 

no_l!af_exists 

ALIAS_DOES_NOT_ EXIST 

NO_CHILD_IO_DELETE 

G_AST_FULL 

L_AST_FULL 

LOCAL_MEMORY_FULL 

GLOBAL_MEMORY_F  ULL 

SECONDARY  STORAGE  FULL 


Figure  31:  Success  Codes 
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Chapter  XII 
STATUS  OF  RESEABCH 


A.  CONCLUSIONS 

The  memory  manager  design  utilized  stare  of  the  art 
software  techniques  and  hardware  devices.  The  design  was  de¬ 
veloped  based  upon  ZILOG'S  Z8001  sixteen  bit  segmented  mi¬ 
croprocessor  used  in  conjunction  with  the  Z8010  Memory  Man¬ 
agement  Unit  [23],  A  microprocessor  which  supports 
segmentation  is  required  to  provide  access  control  of  the 
stored  data.  The  actual  implementation  of  the  selected 
thread  was  conducted  upon  the  Z8Q02  non-segmented  micropro¬ 
cessor  without  the  Z8010  MHU. 

While  information  security  requires  that  the  micropro¬ 
cessor  support  segmentation,  the  memory  manager  was  devel¬ 
oped  to  be  configuration  independent.  The  design  will  sup¬ 
port  a  multi-processor  environment,  and  can  be  easily 
implemented  upon  any  microprocessor  or  secondary  storage 
device.  The  loop  free  modular  design  facilitates  any  re¬ 
quired  expansion  or  modification. 

Global  bus  contention  is  minimized  oy  the  memory  manag¬ 
er.  Segments  are  stored  in  global  memory  only  if  they  are 
shared  and  writable.  Secondary  storage  is  accessed  only  if 
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the  segment  does  not  currently  reside  in  global  memory  or 
some  local  memory.  The  controlled  sharing  of  segments  optim¬ 
izes  main  memory  usage. 

The  storage  of  the  alias  tables  in  secondary  storage 
supports  the  recreation  of  user  file  hierarchies  following  a 
system  crash.  The  aliasing  scheme  used  to  address  segments 
supports  system  security  by  not  allowing  the  segment's  memo¬ 
ry  location  or  unique  identification  to  leave  the  memory 
manager. 

The  design  of  the  distributed  kernel  was  clarified  by 
assigning  the  MMU  image  management  to  the  memory  manager. 
The  transfer  of  responsibility  for  memory  allocation  and 
deallocation  from  the  supervisor  to  the  memory  manager  pro¬ 
vides  support  for  dynamic  memory  management. 

In  conclusion,  the  memory  manager  process  will  securely 
manage  segments  in  a  multi-processor  environment.  The  pro¬ 
cess  is  efficient,  and  is  configuration  independent.  The 
primitives  provided  by  the  memory  manager  will  support  the 
construction  of  any  desired  supervisor/user  process  built 
upon  the  kernel. 
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B.  FOLLOW  ON  WORK 

There  are  several  possible  areas  in  the  SASS  design  that 
can  be  looked  into  for  continued  research.  The  complete  im¬ 
plementation  of  the  memory  manager  design  (refine  and  optim¬ 
ize  the  current  PLZ/SYS  code)  is  one  possibility.  Other  pos¬ 
sibilities  include  the  implementation  of  dynamic  memory 
management,  and  modifying  the  interface  of  the  memory  manag¬ 
er  with  the  distributed  kernel  using  eventcounts  and  se¬ 
quencers  for  inter-process  communication. 

The  implementation  of  the  supervisor  has  not  been  ad¬ 
dressed  to  date.  Areas  of  research  include  the  implmenta- 
tion  of  the  file  manager  and  input/output  processes,  and  the 
complete  design  and  implementation  of  the  user-host  proto¬ 
cols.  The  implementation  of  the  gatekeeper,  and  system  ini- 

, 

tialization  are  other  possible  research  areas.  Dynamic  pro¬ 
cess  creation  and  deletion,  and  the  introduction  of 
multi-level  hosts  could  also  prove  interesting. 


PART  D 


AN  I HP LB KENT AT ION  OF  MULTIPROGRAMMING  AND 
PROCESS  MANAGEMENT  FOE  A  SECURITY  KERNEL 
OPEBATING  SYSTEM 


This  section  contains  updated  excerpts  from  a  Naval  Post¬ 
graduate  School  MS  Thesis  by  S.  L.  Reitz  [12].  The  origins 
of  these  excerpts  are: 


INTRODUCTION 

IMPLEMENTATION 

CONCLUSION 


from  Chapter  I 
from  Chapter  IV 
from  Chapter  V 


Minor  changes  have  been  made  for  integration  into  this  repor 


Chapter  XIII 
INTRODUCTION 

The  application  of  contemporary  microprocessor  technolo¬ 
gy  to  the  design  of  large-scale  multiple  processor  systems 
offers  many  potential  benefits.  The  cost  of  high-power  com¬ 
puter  systems  could  be  reduced  drastically;  fault  tolerance 
in  critical  real-time  systems  could  be  improved;  and  compu¬ 
ter  services  could  be  applied  in  areas  where  their  use  is 
not  now  cost  effective.  Designing  such  systems  presents 
many  formidable  problems  that  have  not  been  solved  by  the 
specialized  single  processor  systems  available  today. 

Specifically,  there  is  an  increasing  demand  for  computer 
systems  that  provide  protected  storage  and  controlled  access 
for  sensitive  information  to  be  shared  among  a  wide  range  of 
users.  Data  controlled  by  the  Privacy  Act,  classified  De¬ 
partment  of  Defence  (DoD)  information,  and  the  transactions 
of  financial  institutions  are  but  a  few  of  the  areas  which 
require  protection  for  multiple  levels  of  sensitive  informa¬ 
tion.  Multiple  processor  systems  which  share  data  are  well 
suited  to  providing  such  services  -  if  the  data  security 
problem  can  be  solved. 

A  solution  to  these  problems  -  a  multiprocessor  system 
design  with  verifiable  information  security  -  is  offered  in 
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a  family  of  secure,  distributed  multi-microprocessor  operat¬ 
ing  systems  designed  by  O'Connell  and  Bichardson  [7],  A 
subset  of  this  family,  the  Secure  Archival  Storage  System 
(SASS)  [9,5],  has  been  selected  as  a  testbed  for  the  general 
design.  SASS  will  provide  consolidated  file  storage  for  a 
network  of  possibly  dissimilar  "host"  computers.  The  system 
will  provide  controlled,  shared  access  to  multiple  levels  of 
sensitive  information  (Figure  32)  . 

This  thesis  presents  an  implementation  of  a  basic  moni¬ 
tor  for  the  O' Connell-Richardson  family  of  operating  sys¬ 
tems.  The  monitor  provides  multiprogramming  and  process 
management  functions  specifically  addressed  to  the  control 
of  physical  processor  resources  of  SASS.  Concurrent  thesis 
work  [7]  is  developing  a  detailed  design  for  a  security  ker¬ 
nel  process,  the  Memory  Manager,  which  will  manage  SASS  me¬ 
mory  resources. 
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Chapter  XIV 
IMPLEMENTATION 

Implementation  of  the  distributed  kernel  was  simplified 
by  the  hierarchical  structure  of  the  design  for  it  permit¬ 
ted  methodical  bottom-up  construction  of  a  series  of  extend¬ 
ed  machines.  This  approach  was  particularly  useful  in  this 
implementation  since  the  bare  machine,  the  Z8000  Developmen¬ 
tal  Module,  was  provided  with  only  a  small  amount  of  soft¬ 
ware  support. 

A .  DEVELOPMENTAL  SUPPORT 

A  Zilog  MCZ  Developmental  System  provided  support  in  de¬ 
veloping  Z3000  machine  code.  It  provided  floppy  disk  file 
management,  a  text  editor,  a  linker  and  a  loader  that  creat¬ 
ed  an  image  of  each  Z8000  load  module. 

A  Z8000  Developmental  Module  (DM)  provided  the  necessary 
hardware  support  for  operation  of  a  Z8002  non-segmented  mi¬ 
croprocessor  and  16K  words  (32K  bytes)  of  dynamic  RAM.  It 
included  a  clock,  a  USART,  serial  and  parallel  I/O  support, 
and  a  2K  PROM  monitor. 

The  monitor  provided  access  to  processor  registers  and 
memory,  single  step  and  break  point  functions,  basic  I/O 
functions,  and  a  download/upload  capability  with  the  MCZ 

system. 


Sines  a  segmented  version  of  the  processor  was  not 
available  for  system  development,  segmentation  hardware  was 
simulated  in  software  as  an  MMU  image  (see  Figure  33)  .  Alt¬ 
hough  this  data  structure  did  not  provide  the  hardware  sup¬ 
port  (traps)  required  to  protect  segments  of  the  kernel  do¬ 
main,  it  preserved  the  general  structure  of  the  design. 
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Figure  33:  MMU_II1AGE 
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B.  INNER  TRAFFIC  CONTRO£LM 

The  Inner  Traffic  Controller  runs  on  the  bare  machine  to 
create  a  virtual  environment  for  the  remainder  of  the  sys¬ 
tem.  Only  this  module  is  dependent  on  the  physical  proces¬ 
sor  configuration  of  the  system.  All  higher  levels  see  only 
a  set  of  running  virtual  processors.  A  kernel  data  base, 
the  Virtual  Processor  Table  is  used  by  the  Inner  Traffic 
Controller  to  create  the  virtual  environment  of  this  first 
level  extended  machine.  A  source  listing  of  the  Inner 
Traffic  Controller  module  is  contained  in  Appendix  G. 

1 •  Victual  Processor  Table  (VPT) 

The  VPT  is  a  data  structure  of  arrays  and  records  that 
maintains  the  data  used  by  the  Inner  Traffic  Controller  to  > 
multiplex  virtual  processors  on  a  real  processor  and  to 
create  the  extended  instruction  set  that  controls  virtual 
processor  operation  (see  Figure  34) .  There  is  one  table  for 
each  physical  processor  in  the  system.  Since  this  implemen¬ 
tation  was  for  a  uniprocessor  system  (the  Z80Q0  DM) ,  only 
one  table  was  necessary. 

The  table  contains  a  LOCK  which  supports  an  exclusion 
mechanism  for  a  multiprocessor  system.  It  was  provided  in 
this  implementation  only  to  preserve  the  generality  of  the 
design. 

The  Descriptor  Base  Register  (DBR)  binds  a  process  to  a 
virtual  processor.  The  DBR  points  to  an  HiHJ_IMAGE  contain- 
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Figure  34:  Virtual  Processor  Table 

ing  the  list  of  descriptors  for  segments  in  the  process  ad¬ 
dress  space. 

A  virtual  processor  (VP)  can  be  in  one  of  three  states: 
running,  ready,  and  waiting  (Figure  35).  A  running  VP  is 
ourrently  scheduled  on  a  real  processor.  A  ready  VP  is 
ready  to  be  scheduled  when  selected  by  the  level-1  schedul- 
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ing  algorithm.  A  waiting  VP  is  awaiting  a  message  from  some 
other  VP  to  place  it  in  the  ready  list.  In  the  meantime  it 
is  not  in  contention  for  the  real  processor. 


I 
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2.  Level- 1  Scheduling 

Virtual  processor  state  changes  are  initiated  by  the  in¬ 
ter-virtual-processor  communication  mechanisms,  SIGNAL  and 
WAIT.  These  level- 1  instructions  implement  the  scheduling 
policy  by  determining  what  virtual  processor  to  bind  to  the 
real  processor.  The  actual  binding  and  unbinding  is  per¬ 
formed  by  a  Processor  switching  mechanism  called  SWAP_DB8 
[14].  Processor  switching  implies  that  somehow  the  execu¬ 
tion  point  and  address  space  of  a  new  process  are  acquired 
by  the  processor.  Care  must  be  taken  to  insure  that  the  old 
process  is  saved  and  the  new  process  loaded  in  an  orderly 
manner.  A  solution  to  this  problem,  suggested  by  Saltzer 
[14],  is  to  design  the  switching  mechanism  so  that  it  is  a 
common  procedure  having  the  same  segment  number  in  every  ad¬ 
dress  space. 

In  this  implementation  a  processor  register  (B14)  was 
reserved  within  the  switching  mechanism  for  use  as  a  DBR. 
Processor  switching  was  performed  by  saving  the  old  execu¬ 
tion  point  (  i.e.,  processor  registers  and  flag  control 
word) ,  loading  the  new  DBB  and  then  loading  the  new  execu¬ 
tion  point.  The  processor  switch  occurs  at  the  instant  the 
DBS  is  changed  (see  Figure  36) .  Because  the  switching 
procedure  is  distributed  in  the  same  numbered  segment  in  all 
address  spaces,  the  "next"  instruction  at  the  instant  of  the 
switch  will  have  the  same  offset  no  matter  what  address 
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space  the  processor  is  in.  This  is  the  key  to  the  proper 
operation  of  SWAP_DBR. 

To  convert  this  switching  mechanism  to  segmented  hard¬ 
ware  it  is  necessary  merely  to  replace  Si AP_D BR  with  special 
I/O  block-move  instructions  that  save  the  contents  of  the 
MMU  in  the  appropriate  MMU_IMAGE  and  load  the  contents  of 
the  new  MMU_IMAGE  into  the  MMU. 

a.  Getwork 

SWAP_DBR  is  contained  within  an  internal  Inner  Traffic 
Controller  procedure  called  GETWORK.  In  addition  to  multi¬ 
plexing  virtual  processors  on  the  CPU,  GETWORK  interprets 
the  virtual  processor  status  flags,  IDLE  and  PREEMPT,  and 
modifies  VP  scheduling  accordingly  in  an  attempt  to  keep  the 
CPU  busy  doing  useful  work. 

There  are  actually  two  classes  of  idle  processes  within 
the  system.  One  class  belongs  to  the  Traffic  Controller. 
Conceptually  there  is  a  ready  level-2  idle  process  for  each 
virtual  processor  available  to  the  Traffic  Controller  for 
scheduling.  When  a  running  process  blocks  itself,  the 
Traffic  Controller  schedules  the  first  ready  process.  This 
will  be  an  idle  process  if  no  supervisor  processes  are  in 
the  ready  list. 

The  second  class  of  idle  process  exists  in  the  kernel. 
The  kernel  Idle  process  is  permanently  bound  to  the  lowest 
priority  virtual  processor. 
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Figure  36:  SWAP  DBR 
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The  distinction  is  made  between  these  classes  because  of 
the  need  to  Keep  the  CPU  busy  doing  useful  work  whenever 
possible.  There  is  no  need  for  GETWOEK  to  schedule  a  lev¬ 
el-2  idle  process  that  has  been  loaded  on  a  virtual  proces¬ 
sor,  because  the  idle  process  does  no  useful  work.  The  vir¬ 
tual  processor  IDLE_FLAG  indicates  that  a  virtual  processor 
has  been  loaded  with  a  level-2  idle  process.  GETWOEK  will 
schedule  this  virtual  processor  only  if  the  PREEMPT  flag  is 
also  set.  The  PREEMPT  flag  is  a  signal  from  the  Traffic 
Controller  that  a  supervisor  process  is  now  ready  to  run. 

When  GETWORK  can  find  no  other  ready  virtual  processors 
with  IDLE  and  PREEMPT  flags  off,  it  will  select  the  virtual 
processor  permanently  bound  to  the  kernel  Idle  process. 
Only  then  will  the  Idle  process  actually  run  on  the  CPU. 

Getwork  contains  two  entry  points.  The  first,  a  normal 
entry,  resets  the  preempt  interrupt  return  flag.  (30  is  re¬ 
served  for  this  purpose  within  GETWOEK.)  The  second,  a 
hardware  interrupt  entry  point,  contains  an  interrupt  han¬ 
dler  which  sets  the  preempt  interrupt  return  flag.  The  DBR 
(R 1 4)  must  also  be  set  to  the  current  value  by  any  procedure 
that  calls  GETWORK  in  order  to  oermit  the  SWAP  DBR  portion 

I 

of  GETWORK  to  have  access  to  the  scheduled  process's  address 
space.  Upon  completion  of  the  processor  switch,  GETWOEK  ex- 
mines  the  interrupt  return  flag  to  determine  whether  a  mor¬ 
al  return  or  an  interrupt  return  is  required. 
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The  hardware  interrupt  entry  point  in  GETWORK  supports 
the  technique  used  to  initialize  the  system.  Each  process 
address  space  contains  a  kernel  domain  stack  segment  used  by 
SWAP-DBR  in  GETWORK  to  save  and  restore  VP  states.  For  the 
same  reason  that  SWAP-DBR  is  contained  in  a  system  wide  seg¬ 
ment  number,  the  stack  segment  in  each  process  address  space 
will  also  have  the  same  number  (Segment  #1  in  this  implemen¬ 
tation)  .  Each  stack  segment  is  initially  created  as  though  i|l 
it's  process  had  been  previously  preempted  by  a  hardware  in¬ 
terrupt.  This  greatly  simplifies  the  initialization  of  pro¬ 
cesses  at  system  generation  time.  The  details  of  system  in¬ 
itialization  will  be  described  later  in  this  chapter.  It  is 
important  to  note  here,  however,  that  GETWORK  must  be  able 
to  determine  whether  it  was  invoked  by  a  hardware  preempt 
interrupt  or  by  a  normal  call,  before  it  can  execute  a  re- *1 
turn  to  the  calling  procedure.  This  is  because  a  hardware  ■(! 
interrupt  causes  three  items  to  be  placed  on  the  system 
stack:  the  return  location  of  the  caller,  the  flag  control 

word,  and  the  interrupt  identifier,  whereas  a  normal  call 
places  only  the  return  location  on  the  stack.  Therefore,  in 
order  to  clean  up  the  stack,  GETWORK  must  execute  an  inter¬ 
rupt  return  (assembly  instruction : IRET)  if  entry  was  via  the 
hardware  preempt  handler  (i.e.,  RO  set).  This  instruction 
will  pop  the  three  items  off  the  stack  and  return  to  the  ap¬ 
propriate  location.  If  the  interrupt  return  flag,  RO,  is 
off,  a  normal  return  is  executed. 
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During  normal  operation,  SWAP-DBR  manipulates  process 
stacks  to  save  the  old  VP  state  and  load  the  new  VP  state. 
This  action  proceeds  as  follows  (Figure  37)  : 

1.  The  Flag  Control  tford  (FCW)  ,  the  Stack  Pointer  (R15) 
and  the  preempt  return  flag  (RO)  are  saved  in  the  old 
VP's  kernel  stack. 

2.  The  DBR  (R 1 4 )  is  loaded  with  the  new  VP's  DBR.  This 
permits  access  to  the  address  space  of  the  new  pro¬ 
cess  . 

3.  The  Flag  Control  Word  (FCW)  ,  the  Stack  Pointer  (R 1 5 ) 
and  the  Interrupt  Return  Flag  (RO) ,  are  loaded  into 
the  appropriate  CPU  registers. 

4.  SO  is  tested.  If  it  is  set,  GETKORK  will  execute  an 
interrupt  return.  If  it  is  off,  a  normal  return  oc¬ 
curs. 

By  constructing  GETWORK  in  this  way,  both  system  initializa¬ 
tion  and  normal  operations  can  be  handled  in  the  same  way. 
A  high  level  GETWORK  algorithm  is  given  in  Figure  38. 
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Figure  37:  Kernel  Stack  Segments 
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GETWORK  Procedure  (DBS  =  R14) 

Begin 

Reset  Interrupt.  Return  Flag  (RO) 

Skip  hardware  preempt  handler 

Hardware  Preempt  Entry: 

Set  D3R 

Save  CPU  registers 

Save  supervisor  stack  pointer 

Set  Interrupt  Return  Flag  (RO) 

Get  first  ready  VP 

Do  while  not  select 
If  Idle  flag  is  set  then 
if  Preempt  flag  is  set  then 
select 
else 

get  next  ready  VP 
end  if 
else 
select 
end  if 
end  do 

SWAP_DBR : 

Save  old  VP  registers  in  stack  segment 
Swap  dbr  (R14) 

Load  new  VP  registers  in  stack  segment 

If  Interrupt  Return  Flag  is  set  then 
unlock  VPT 

simulate  GATEKEEPER  exit: 

Call  TEST_VPREEMPT 

Restore  supervvisor  registers 

Restore  supervvisor  stack  pointer 

Execute  Interrupt  Return  (IRET) 
end  if 

Execute  normal  return 
end  GETWORK 


Figure  38:  GETWORK 
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3.  Virtual  Processor  Instruction  Set 

The  heart  of  the  SASS  scheduling  mechanism  is  the  inter¬ 
nal  procedure,  GETWORK.  It  provides  a  powerful  internal 
primitive  for  use  by  the  virtual  processors  and  greatly  sim¬ 
plifies  the  design  of  the  virtual  processor  instruction  set. 
Virtual  processor  instructions  perform  three  types  of  func¬ 
tions:  multiprogramming,  process  management  and  virtual  in¬ 

terrupts. 

SIGNAL  and  WAIT  provide  synchronization  and  communica¬ 
tion  between  virtual  processors.  They  multiplex  virtual 
processors  on  a  CPU  to  provide  multiprogramming.  This  im¬ 
plementation  used  a  version  of  the  signal  and  wait  algor¬ 
ithms  proposed  by  Saltzer  [14].  In  the  SASS  design  each  CPU  I' 
is  provided  with  a  unique  (fixed)  set  of  virtual  processors. 
The  interaction  among  virtual  processors  is  a  result  of  mul¬ 
tiprogramming  them  on  the  real  processor.  Only  one  virtual 
processor  is  able  to  access  the  VPT  at  a  time  because  of  the 
use  of  the  VPT  LOCK  (SPIN_LOCK)  to  provide  mutual  exclusion. 
Therefore  race  and  deadlock  conditions  will  not  develop  and 
the  signal  pending  switch  used  by  Saltzer  is  not  necessary. 

This  implementation  also  included  message  passing  mecha- 
mism  not  provided  by  Saltzer.  The  message  slots  available 
for  use  by  virtual  processors  are  initially  contained  in  a 
queue  pointed  to  by  FREE-LIST.  When  a  message  is  sent  from 
one  VP  to  another,  a  message  slot  is  removed  from  the  free 
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list  and  placed  in  a  FIFO  message  queue  belonging  to  the  VP 
receiving  the  message.  The  head  of  each  VP's  message  queue 
is  pointed  to  by  MSG-LIST.  Each  message  slot  contains  a 
message,  the  ID  of  the  sender,  and  a  pointer  to  the  next 
message  in  the  list  (either  the  free  list  or  the  VP  message 
list. 

IDLE  and  SWAP_VDBR  provide  the  Traffic  Controller  with  a 
means  of  scheduling  processes  on  the  running  VP. 

SET_VP3  EEMPT  and  TEST_VPRSEMPT  install  a  virtual  inter¬ 
rupt  mechanism  in  each  virtual  processor.  When  the  Traffic 
Controller  determines  that  a  virtual  processor  should  give 
up  its  process  because  a  higher  priority  process  is  now 
ready,  it  sets  the  PREEMPT  flag  in  that  VP.  Then,  even  if 
an  idle  process  is  loaded  on  the  VP,  it  will  be  scheduled 
and  will  be  loaded  with  the  first  ready  process. 
Test_VPreempt  is  a  virtual  interrupt  unmasking  mechanism 
which  forces  a  process  to  examine  the  preempt  flag  each  time 
it  exists  from  the  kernel. 

a.  Wait 

SAIT  provides  a  means  for  a  virtual  processor  to  move 

i 

itself  from  the  running  state  to  the  waiting  state  when  it 
has  no  more  work  to  do.  It  is  invoked  only  for  system 
events  that  are  always  of  short  duration.  It  is  supported 
by  three  internal  Procedures. 
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SPIN_LOCK  enables  the  running  VP  to  gain  control  of  the 
Virtual  Processor  Table.  This  procedure  is  only  necessary 
in  a  multiprocessor  environment.  The  running  VP  will  have 
to  wait  only  a  short  amount  of  time  to  gain  control  of  the 
VPT.  SPIN_LOCK  returns  when  the  VP  has  locked  the  VPT. 

GETWORK  loads  the  first  eligible  virtual  processor  of 
the  ready  list  on  the  real  processor.  Before  this  procedure 
is  invoked,  the  running  VP  is  placed  in  the  ready  state. 
Both  ready  and  running  VP's  are  members  of  a  FIFO  gueue. 
GETWORK  selects  the  first  VP  in  this  ready  list,  loads  it  on 
the  CPU,  and  places  it  in  the  running  state.  When  GETWORK 
returns,  the  first  VP  of  the  gueue  will  always  be  running 
and  the  second  will  be  the  first  VP  in  the  ready  gueue. 

GET_FIRST_MESSAGE  returns  the  first  message  of  the  mes¬ 
sage  list  (also  managed  as  a  FIFO  gueue)  associated  with  the 
running  VP.  The  action  taken  by  WAIT  is  as  follows: 

WAIT  Procedure  (Returns:  Msg,  Sender_ID) 

Begin 

Lock  VPT  (call  SPIN_LOCK) 

If  message  list  empty  (i.e.,  no  work)  Then 
Move  VP  from  Running  to  Waiting  state 
Schedule  first  eligible  Ready  VP  (call  GETWORK) 

end  if 

(NOTE:  process  suspended  here  until 
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it  receives  a  signal  and  is 
selected  by  GETWORK . ) 

Set  first  message  from  message  list 
(call  GET_FIRST_hSG ) 

Unlock  VPT 
Return 
end  WAIT 


If  the  running  virtual  processor  calls  WAIT  and  there  is 
a  message  in  its  message  list  (placed  there  when  another  VP 
signaled  it)  it  will  get  the  message  and  continue  to  run. 
If  the  message  list  is  empty  it  will  place  itself  in  the 
wait  state,  schedule  the  first  ready  virtual  processor,  and 
move  it  to  the  running  state.  The  virtual  processor  will 
remain  in  the  waiting  state  until  another  running  V?  sends 
it  a  message  (via  SIGNAL).  It  will  then  move  to  the  ready 
list.  Finally  it  will  be  selected  by  GETWORK,  the  next  in¬ 
structions  of  WAIT  will  be  executed,  it  will  receive  the 
message  for  which  it  was  waiting,  and  it  will  return  to  the 
caller. 
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b.  Signal 

Messages  are  passed  between  virtual  processors  by  the 
instruction,  SIGNAL,  which  uses  four  internal  procedures, 
S PIN_LOCK,  ENTER_MSG_LIST ,  MA KE_R EADY ,  and  GETWOEK. 

SPIN_LOCK ,  as  explained  above  insures  that  only  one  vir¬ 
tual  processor  has  control  of  the  Virtual  Processor  Table  at 
a  time. 

ENTER_MSG_LIST  manages  a  FIFO  message  gueue  for  each 
virtual  Processor  and  for  free  messages.  This  gueue  is  of 
fixed  maximum  length  because  of  the  implementation  decision 
to  restrict  the  use  of  SIGNAL.  A  running  VP  can  send  no 
more  than  one  message  (SIGNAL)  before  it  receives  a  reply 
(i.e.  ,  WAIT's  for  a  message).  Therefore  if  there  are  N  vir¬ 
tual  processors  per  real  processors,  the  message  gueue 
length,  L,  is: 

L  =  N  -  1 

MAKE_READY  manages  the  virtual  processor  ready  queue. 
If  a  message  is  sent  to  a  VP  in  the  waiting  state, 
MAKE_READY  wakes  it  up  (it  places  it  in  the  ready  state)  and 
enters  it  in  the  ready  list.  If  a  running  VP  signals  a 
waiting  VP  of  higher  priority,  it  will  place  itself  back  in 
the  ready  state  and  the  higher  priority  VP  will  be  selected. 
The  action  taken  by  signal  is  as  follows: 

SIGNAL  Procedure  (Message,  Destination_VP) 

Begin 
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Lock  VPT  (call  SPI N_LOCK) 

Send  message  (call  ENTEB_MSG_LIST) 
If  signaled  VP  is  waiting  Then 
Wake  it  up  and  make  it  ready 
(call  N AKE_B EADI) 
end  if 

Put  running  VP  in  ready  state. 
Schedule  first  elgible  ready  VP 
(call  GETWOBK) 

Unlock  VPT 

Return  (Success_ccde) 

End  SIGNAL 


c.  SW  AP_V  DBR 

SWAP_VDBR  contains  the  same  processor  switching  mechan¬ 
ism  used  in  SWAP_DBBr  but  applies  it  to  a  virtual  processor 
rather  than  a  real  processor.  Switching  is  quite  simple  in 
this  virtual  environment  because  both  processor  execution 
point  and  address  space  are  defined  by  the  Descriptor  Base 
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Register.  SWAP_VDBR  is  invoked  by  the  Traffic  Controller  to 
load  a  new  process  on  a  virtual  processor  in  support  of  lev¬ 
el-2  scheduling.  It  uses  GETWORK  to  control  the  associated 
level-1  scheduling.  The  action  taken  by  SWAP_VDBR  is: 

SW AP_VDBR  Procedure  (New_DBR) 

Begin 

Lock  VPT  (call  SPIN_LOCK) 

Load  running  VP  with  New_DBR 
Place  running  VP  in  ready  state 
Schedule  first  eligible  ready  VP 
(call  GETWORK) 

Unlock  VPT 
Return 

End  SWAP  VDBR 


In  this  implementation  one  restriction  is  placed  upon 
the  use  of  this  instruction.  If  a  virtual  processor's  mes¬ 
sage  list  contains  at  least  one  message,  it  can  not  give  up 
its  current  DBR.  This  problem  is  avoided  as  the  natural  re¬ 
sult  of  using  SIGNAL  and  WAIT  only  for  system  events,  and 
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"masking"  preempts  within  the  kernel.  If  this  were  permit¬ 
ted,  the  messages  would  lose  their  context.  (The  messages 
in  a  VP_MS3_LIST  are  actually  intended  for  the  process  load¬ 
ed  on  the  VP.) 

d.  IDLE 

The  IDLE  instruction  loads  the  Idle  DBB  on  the  running 
virtual  processor.  Only  virtual  processors  in  contention 
for  process  scheduling  will  be  loaded  by  this  instruction. 
(The  Traffic  Controller  is  not  even  aware  of  virtual  proces¬ 
sors  permanently  bound  to  kernel  processes.) 

IDLE  has  the  same  scheduling  effect  as  SK  AP_V  DBS,  but  it 
also  sets  the  I DLE_FL AG  on  the  scheduled  VP.  The  distinc¬ 
tion  is  made  between  the  two  cases  because,  although  the 
Traffic  Controller  must  schedule  an  Idle  process  on  the  VP 
if  there  are  no  other  ready  processes,  the  Inner  Traffic 
Controller  does  not  wish  to  schedule  an  Idle  V?  if  there  is 
an  alternative.  This  would  be  a  waste  of  physical  processor 
resources.  The  setting  of  the  IDLE_FLAG  by  the  Traffic 
Controller  aids  the  Inner  Traffic  Controller  in  making  this 
scheduling  decision.  Logically,  there  is  an  idle  process 
for  each  VP;  actually  the  same  address  space  (DBR)  is  used 
for  all  idle  processes  for  the  same  CPU,  since  only  one  will 
run  at  a  time.  As  previously  explained,  virtual  processors 
loaded  by  this  instruction  will  be  selected  by  GETWORK  only 
to  give  the  Idle  process  away  for  a  new  process  in  response 
to  a  virtual  preempt  interrupt.  The  action  of  IDLE  is: 
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IDLE  Procedure 
Begin 

Lock  VPT  (call  SPIN_LOCK) 

Load  running  VP  with  Idle  DBH 
Set  VP's  I DLE_FLAG 
Place  running  VP  in  ready  state 
Schedule  first  elgible  ready  VP 
(call  GETWORK) 

|  jj 

Unlock  VPT 
Return 
End  IDLE 


e.  SET_VPREEMPT 

SET_VPR EEMPT  sets  the  preempt  interrupt  flag  on  a  speci¬ 
fied  virtual  processor.  This  forces  the  virtual  processor 
into  level- 1  scheduling  contention,  even  if  it  is  loaded 
with  an  Idle  process.  The  instruction  retrieves  an  idle 
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virtual  processor  in  the  same  way  a  hardware  preempt  ret¬ 
rieves  an  idle  CPU  by  forcing  the  VP  to  be  selected  by 
GETWORK.  The  only  difference  between  the  two  cases  is  the 
entry  point  used  in  GETWORK.  The  action  of  SET_VPREEflPT  is; 

SET_VPREEMPT  Procedure  (VP) 

Begin 

Set  VP'S  PREEMPT  flag 
If  VP  belongs  to  another  CPU  Then 
send  hardware  interrupt 
end  if 
Return 

End  SET  ’/PREEMPT 


Since  the  action  is  a  safe  sequence,  no  deadlocks  or 
race  conditions  will  arise  and  no  lock  is  required  on  the 
7PT. 

f.  TEST  7PREEMPT 
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Within  the  kernel  of  a  multiprocessor  system  all  process 
interrupts  (which  excludes  system  I/O  interrupts)  are 
masked.  If  process  interaction  results  in  a  virtual  preempt 
being  sent  to  the  running  virtual  processor  by  another  CPU, 
it  will  not  be  handled  since  GETWQRK  has  already  been  in¬ 
voked.  TEST_V PREEMPT  provides  a  virtual  preempt  interrupt 
unmasking  mechanism. 

TEST„VPREEMPT  mimics  the  action  of  a  physical  CPU  when i 
interrupts  are  unmasked.  It  forces  the  process  execution 
point  back  down  into  the  kernel  each  time  the  process  at¬ 
tempts  to  leave  the  kernel  domain,  where  the  preempt  flag  of 
the  running  VP  is  examined.  If  the  flag  is  off, 
TEST_VPR2EMPT  returns  and  the  execution  point  exits  through 
the  Gatekeeper  into  the  supervisor  domain  of  the  process  ad¬ 
dress  space  as  described  above.  However,  if  the  PREEMPT 
flag  is  on,  the  TEST_VPREEMPT  executes  a  virtual  interrupt 
handler  located  in  the  Traffic  Controller.  This  jump  from 
the  Inner  Traffic  Controller  to  the  Traffic  Controller 
(TC_PREEMPT_HANDLER)  is  a  close  parallel  to  the  action  of  a 
CPU  in  response  to  a  hardware  interrupt,  that  is  a  jump  to 
an  interrupt  handler.  The  Traffic  Controller  Preempt  Han¬ 
dler  forces  level-2  and  level-1  scheduling  to  proceed  in  the 
normal  manner.  The  preempt  handler  forces  the  Traffic  Cont¬ 
roller  to  examine  the  APT  and  to  apply  the  level-2  schedul¬ 
ing  algorithm,  TC_GETWORK.  if  the  APT  has  been  changed 
since  the  last  invocation  of  this  scheduler,  it  will  be  re- 
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when  the 


fleeted  in  the  scheduling  selections.  Eventually 
running  VP's  preempt  flag  is  tested  and  found  to 
TEST_VPREEMPT  will  return  to  the  Gatekeeper  where 
cess  execution  point  will  finally  make  a  normal 
its  supervisor  domain.  TEST_VPREEMPT  performs  the 
action: 

TEST_VPR  EEMPT  Procedure 
Begin 

Do  while  running  VP's  PREEMPT  flag  is  set 
Reset  PREEMPT  flag 
Call  preempt  handler 

(call  TC_PREEMPT_H ANDLER) 

End  do 
Return 

End  TEST  VPREEMPT 


be  reset, 
the  pro¬ 
exit  into 
following 
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1 

C.  TRAFFIC  CONTROLLER  .1  , 

The  Traffic  Controller  runs  in  a  virtual  environment 
created  by  the  Inner  Traffic  Controller.  It  sees  a  set  of 
running  virtual  processor  instructions:  SWAP_VDB3,  IDLE, 

SET_VPREEMPT,  and  RONNING_VP,  and  provides  a  scheduler, 
TC_GETWORK,  which  multiplexes  processes  on  virtual  proces¬ 
sors  in  response  to  process  interaction.  It  also  creates  a 
level-2  instruction  set:  ADVANCE,  AWAIT,  and  PSOCESS_CLASS, 
which  is  available  for  use  by  higher  levels  of  the  design. 
The  Traffic  Controller  uses  a  global  data  base,  the  ACTIVE 
PROCESS  TABLE  to  support  its  operation. 

1  l 

1 .  Active  Process  Table  (APT) 

The  Active  Process  Table  is  a  system-wide  kernel  data¬ 
base  containing  entries  for  each  supervvisor  process  in  SASS 
(Figure  39)  .  It  is  indexed  by  active  process  ID.  The 
structure  of  the  APT  closely  parallels  that  of  the  Virtual 
Processor  Table.  It  contains  a  LOCK  to  support  the  imple¬ 
mentation  of  a  mutual  exclusion  mechanism,  a  R(JNNING_LIST, 
and  a  HEADY_LIST_HEAD .  The  Traffic  Controller  is  only  con¬ 
cerned  with  virtual  processors  that  can  be  loaded  with  su¬ 
pervisor  processes.  Since  two  VP's  are  permanently  bound  to 
kernel  processes  (the  Memory  Manager  and  the  Idle  Process) , 
they  cannot  be  in  contention  for  level-2  scheduling;  the 
Traffic  Controller  is  unaware  of  their  existence;  since 
there  are  a  number  of  available  virtual  processors,  the 
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?.0SNIh*G_LI3 T  was  implemented  as  an  array  indexed  by  VP  ID. 
The  SSiDI_LIST_HZAD  points  to  a  FIFO  gueue  that  includes 
beta  running  and  ready  processes.  Ihe  running  processes 
will  be  at  the  top  of  the  ready  list. 

Because  or  their  completely  static  nature,  idle  process¬ 
es  require  no  entries  in  the  APT.  Logically,  there  is  an 
idle  process  at  the  end  of  the  ready  list  for  each  VP  avai¬ 
lable  to  the  Traffic  Controller.  If  the  ready  list  is  emp¬ 
ty,  rc_G2TWCHK  loads  one  of  tnese  "virtual"  idle  processes 
by  calling  IDL2,  and  enters  a  reserved  identifier,  #IDL2,  in 
the  appropriate  3UNNIXG_LIST  entry.  This  identifier  is  the 
only  data  concerning  idle  processes  that  is  contained  in  the 
APT.  Idle  process  scheduling  considerations  are  noved  down 
to  level-1,  because  the  Inner  Traffic  Controller  knows  about 
physical  processors,  and  can  optimize  CPU  use  by  scheduling 
idle  processes  only  when  there  is  nothing  else  to  do. 

The  subject  access  class,  S_CLA5S,  provides  each  process 
with  a  label  that  is  required  by  level-3  modules  to  enforce, 
the  3 ASS  non-aiscret ionary  security  policy. 
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Figure  39:  Active  Process  Table 


2.  Level- 2  Scheduling 

Above  the  Traffic  Controller,  SASS  appears  as  a  collec¬ 
tion  of  processes  in  one  of  the  three  states:  running, 
ready,  or  blocked.  Running  and  ready  states  are  analogous 
to  the  corresponding  virtual  processor  states  of  the  Inner 
Traffic  Controller.  However,  because  of  the  use  of  event- 
count  synchronization  mechanisms  by  the  Traffic  Controller, 
the  blocked  state  has  a  slightly  different  connotation  than 
the  VP  waiting  state. 

Blocked  processes  are  waiting  for  the  occurrence  of  a 
non-system  event,  e.g. ,  the  event  occurrence  may  be  sig¬ 
nalled  from  the  supervisor  domain.  When  a  specific  event 
happens,  ail  of  the  blocked  processes  that  were  awaiting 
that  event  are  awakened  and  placed  in  the  ready  state.  This 
broadcast  feature  of  event  occurrence  is  more  powerful  than 
the  message  passing  mechanism  of  SIGNAL,  which  must  be  di¬ 
rected  at  a  single  recipient. 

Just  as  SIGNAL  and  WAIT  provide  virtual  processor  multi- 
plixing  in  level-1,  the  eventcount  functions,  ADVANCE  and 
AWAIT,  control  process  scheduling  in  level-2. 


a.  TC_GETWORK 

Level-2  scheduling  is  implemented  in  the  internal  Traff¬ 
ic  Controller  procedure,  TC_G2TW0F.K.  This  procedure  is  in¬ 
voked  by  eventcount  functions  when  a  process  state  change 
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may  have  occurred.  It  loads  the  first  ready  process  on  the 
currently  scheduled  VP  (i.e.,  the  virtual  processor  that  has 
been  scheduled  at  level- 1  and  is  currently  executing  on  the 
CPU)  . 


TC_GETWORK  Procedure 
Begin 

VP_ID  :=  RUNNING_VP 
Do  while  not  end  of  ready  list 
if  process  is  running  then 
get  next  ready  process 
else 

BUNNING_LIST  [VP_ID]  :=  PfiOCESS_ID 
Process  state  :=  running 
SWAP_VDBR 
end  if 
end  do 

If  end  of  running  list  (no  ready  processes)  Then 
RUNNIN G_LIST  :=  # IDLE 
IDLE 
end  if 
Return 

End  TC  GETWORK 
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b.  TC_PREEMPT_HANDLER 

Preempt  interrupts  are  masked  while  a  process  is  execut¬ 
ing  in  the  kernel  domain.  As  the  process  leaves  the  kernel, 
the  gatekeeper  unmasks  this  virtual  interrupt  by  invoking 
TEST_VPREEMPT .  This  instruction  tests  the  scheduled  7P's 
PREEMPT  flag.  If  this  flag  is  off,  the  process  returns  to 
the  Gatekeeper  and  exits  from  the  kernel;  out  if  the  flag  is 
set,  TEST_ VPHEEMPT  calls  the  Traffic  Controller’s  virtual 
preempt  interrupt  handler,  TC_PREEMPT_HANDLEH .  This  handler 
invokes  TC_GETWORK,  which  re-evaluates  level-2  scheduling. 
Eventually,  when  the  schedulers  have  completed  their  func¬ 
tions,  the  handler  will  return  control  to  the  preempted  pro¬ 
cess,  which  will  return  to  te  Gatekeeper  for  a  normal  exit. 
This  sequence  of  events  closely  parallels  the  action  of  a 
hardware  interrupt,  but  in  the  environment  of  a  virtual  pro¬ 
cessor  rather  than  a  CPU.  The  virtualization  of  interrupts 
provides  the  ability  for  one  virtual  processor  to  interrupt 
execution  of  another  that  may,  or  may  not,  be  running  on  a 
CPU  at  that  time.  This  is  provided  without  disrupting  the 
logical  structure  of  the  system.  This  capability  is  parti¬ 
cularly  useful  in  a  multiprocessor  environment  where  the 
target  virtual  processor  may  be  executing  on  another  CPU. 
Because  these  interrupts  will  be  virtualized,  the  operating 
system  will  retain  control  of  the  system.  The  action  of  the 
TC_PREEMPT_H A NDL2 R  is  described  in  the  procedure  below. 
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TC_PSEEMPT_H ANDLER  Procedure 
Beg  in 

Call  WAIT_LOCK 

VP_ID  :=  RUNNING_VP 

Process_ID  :=  RUNNING  LIST  [VP_ID] 

If  process  is  not  idle  Then 
Process  state  :=  ready 
end  if 

Call  TC_GETWORK 
Call  WAIT_UNLOCK 
RETURN 

End  TC_PREEMPT_HANDL2R 

W AIT_L JCK  and  WAIT_UNLOCK  provide  an  exclusion  mechanism 
which  prevents  simultaneous  multiple  use  of  the  APT  in  a 
multiprocessor  configuration.  This  mechanism  invokes  H AIT 
and  SIGNAL  of  the  Inner  Traffic  Controller. 
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3.  Eventcounts 

An  eventcount  is  a  non-decreasing  integer  associated 
with  a  global  object  called  an  event  [11].  The  Event  Manag¬ 
er,  a  level-3  module,  controls  access  to  event  data  when  re¬ 
quired  and  provides  the  Traffic  Controller  with  a  HANDLE,  an 
INSTANCE,  and  a  COONT.  The  values  for  all  eventcounts  (and 
sequencers)  are  maintained  at  the  Memory  Manager  level  and 
are  accessed  by  calls  to  the  Memory  Manager.  The  HANDLE 
provides  the  traffic  controller  with  an  event  ID,  associated 
with  a  particular  segment.  INSTANCE  is  a  mere  specific  de¬ 
finition  of  the  event.  For  example,  each  SASS  supervisor 
segment  has  two  eventcounts  associated  with  it,  a  INSTANCE_1 
and  a  INSTANCE_2,  that  the  supervisor  uses  keep  track  of 
read  and  write  access  to  the  segment  [9].  Eventcounts  pro¬ 
vide  information  concerning  system-wide  events.  They  are 
manipulated  by  the  Traffic  Controller  functions  ADVANCE  and 
AWAIT  and  by  the  Memory  Manager  functions,  READ  and  TICKET. 
A  proposed  high  level  design  for  ADVANCE  and  AWAIT  is  pro¬ 
vided  by  Reitz  [12]. 

a.  Advance 

ADVANCE  signals  the  occurrence  of  an  event  (e.g.,  a  read 
access  to  a  particular  supervisor  segment) .  The  value  of 
the  evenreount  is  the  number  of  ADVANCE  operations  that  have 
been  performed  on  it.  When  an  event  is  advanced,  the  fact 
must  be  broadcast  to  all  blocked  processes  awaiting  it  and 
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the  process  must  be  awakened  and  placed  on  the  ready  list. 
Some  of  the  newly  awakened  processes  may  have  a  higher  pri¬ 
ority  than  some  of  the  running  processes.  In  this  case  a 
virtual  preempt,  SET_VPBE  EMPT  (VP_ID) ,  must  be  sent  to  the 
virtual  processors  loaded  with  these  lower  priority  process¬ 
es. 

b.  Await 

When  a  process  desired  to  block  itself  until  a  particu¬ 
lar  event  occurs,  it  invokes  AWAIT.  This  procedure  returns 
to  the  calling  process  when  a  specified  eventcount  is 
reached.  Its  function  is  similar  to  WAIT. 

c.  Read 

READ  returns  the  current  value  of  the  eventcount.  This 
is  an  Event  Manager  (level  three)  function.  This  module 
calls  the  Memory  Manager  module  to  obtain  the  eventcount  va¬ 
lue. 


d.  Ticket 

TICKET  provides  a  complete  time-ordering  of  possibly 
concurrent  events.  It  uses  a  non-decreasing  integer,  called 
a  sequencer ,  which  is  also  associated  with  each  supervisor 
segment.  As  with  READ,  this  is  an  Event  Manager  function 
that  calls  the  Memory  Manager  to  access  the  sequencer  value. 
Each  invocation  of  TICKET  increments  the  value  of  the  se- 
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quencer  and  returns  it  to  the  caller.  Two  different  uses  of 
ticket  will  return  two  different  values,  corresponding  to 
the  order  in  which  the  calls  were  made. 

D .  SYSTEM  INITIALIZATION 

Because  the  Inner  Traffic  Controller’s  scheduler, 
GETWOHK,  can  accommodate  both  normal  calls  and  hardware  in¬ 
terrupt  jumps,  the  problem  of  system  initialization  is  not 
difficult . 

When  SASS  is  first  started  at  level-1,  the  Idle  VP  is 
running  and  the  memory  manager  VP,  which  has  the  highest 
priority,  is  the  first  ready  virtual  processor  in  the  ready 
list.  All  VP's  available  to  the  Traffic  Controller  for  lev- 
el-2  schedling  are  ready.  Their  IDL2_FLAG ' s  and  PREEMPT 
flags  are  set. 

At  level-2,  all  VP’s  are  loaded  with  idle  processes  and 
all  supervisor  processes  are  ready. 

The  kernel  stack  segment  of  each  process  is  initialized 
to  appear  as  if  it  had  been  saved  by  a  hardware  Preempt  in¬ 
terrupt  (Figure  40)  . 

All  CPCJ  registers  and  the  supervisor  stack  pointer  are 
stored  on  the  stack.  R15  is  reserved  as  the  kernel  stack 
point;  R 1 4  contains  the  DBR .  All  other  registers  can  be 
used  to  pass  initial  parameters  to  the  process.  The  order 
in  which  these  registers  appear  on  the  stack  supports  the 
PLZ/A3M  block-move  instructions. 
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Figure  40:  Initialized  Stack 
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The  status  block  contains  the  current  value  of  the  stack 
pointer,  R15,  and  the  preempt  interrupt  return  flag.  This 
flag  is  set  to  indicate  that  the  process  has  been  saved  by  a 
preempt  interrupt.  The  first  three  items  on  the  stack:  the 
process  entry  point,  the  initial  process  flag  control  word, 
and  an  interrupt  indentifier,  are  also  initialized  to  sup¬ 
port  the  action  of  a  hardware  interrupt. 

To  start-up  the  system,  R14  (the  DBR)  is  set  to  thja  Idle 
process  DBR;  the  CPU  Program  counter  is  assigned  the 
PREEMPT_ENTRY  point  in  GETWOBK ;  tne  CPU  Flag  Control  Word 
(FCW)  is  initialized  for  the  kernel  domain;  and  the  CPU  is 
started.  Because  the  Idle_VP  is  the  lowest  priority  VP  in 
the  system,  it  will  place  itself  back  in  the  ready  state  and 
move  the  Memory  Manager  in  the  running  state.  The  Memory 
Manager  will  execute  an  interrupt  return  because  the  inter¬ 
rupt  return  flag  was  set  by  system  initialization.  There 
will  be  no  work  for  this  kernel  process  so  it  will  call  HAIT 
to  place  itself  in  the  waiting  state.  The  next  ready  VP  is 
idling,  but  since  it's  IDLE_FLAG  and  PREEMPT  flag  are  set, 
GETWORK  will  select  it.  It  too  will  execute  an  interrupt 
return,  but  because  its  PREEMPT  flag  is  set,  it  will  call 
TC_PREEMPT_H ANDLER .  This  will  cause  the  first  ready  process 
to  be  scheduled.  Each  time  a  supervisor  process  blocks  it¬ 
self,  the  next  idle  VP  will  be  selected  and  the  sequence 
will  be  repeated. 
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The  action  described  above  is  in  accord  with  normal  op¬ 
eration  of  the  system.  The  only  unique  features  of  initial¬ 
ization  are  the  entry  point  (PREEMPT-ENTRY:  in  GETWOHK)  anc 
the  values  in  the  initialized  kernel  stack. 

The  implementation  presented  in  this  thesis  has  been  run 
on  a  Z8000  developmental  module.  System  initialization  has 
been  tested  and  executes  correctly.  At  the  current  level  of 
implementation,  no  process  multiplexing  function  is  availa¬ 
ble.  There  is  no  provision  for  unlocking  the  APT  after  an 
initialized  process  has  been  loaded  as  a  result,  a  call  to 
the  Traffic  Controller  (viz.,  ADVANCE  or  AWAIT) .  In  a  pro¬ 
cess  multiplexed  environment  this  would  cause  a  system  dead¬ 
lock.  Once  the  process  left  the  kernel  domain  with  a  locked 
APT,  no  process  would  be  able  to  unlock  it.  The  Traffic 
Controller  must  handle  this  system  initialization  problem. 
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Chapter  XV 
CONCLUSION 

The  implementation  presented  in  this  thesis  created  a 
security  kernel  monitor  that  runs  on  the  Z8000  De velopmental 
Module.  This  monitor  supports  multiprogramming  and  process 
management  in  a  distributed  operating  system.  The  process 
executes  in  a  multiple  virtual  processor  environment  which 
is  independent  of  ike  CPU  configuration. 

This  monitor  was  designed  specifically  to  support  the 
Secure  Archival  Storage  System  (SASS)  [2,  9,  5].  However, 
the  implementation  is  based  on  a  family  of  Operating  Systems 
[7]  designed  with  a  primary  goal  of  providing  multilevel  se¬ 
curity  of  information.  Although  the  monitor  currently  runs 
on  a  single  microprocessor  system,  the  implementation  fully 
supports  a  multiprocessor  design. 

A.  EBCCHaSNDATIONS 

Because  the  Zilog  MMU  is  not  yet  available  for  the  Z8000 
Developmental  Module,  it  was  necesary  to  simulate  the  seg¬ 
mentation  hardware.  As  Seitz  explained  [12],  this  was  ac¬ 
complished  by  reserving  a  CPU  register,  R14,  as  a  Descriptor 
Base  Register  (C’BR)  to  provide  a  link  to  rhe  leaded  addresss 
space.  When  the  MMU  becomes  available,  this  simulation  must 
be  removed.  This  can  be  done  in  two  steps. 
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First 


,  the  addressing  format  must  be  translated  to  the 
segmented  form.  This  requires  no  system  redesign. 

Second,  the  switching  mechanism  most  be  modified  to  ac¬ 
comodated  to  use  the  MMU.  This  can  be  done  by  modifying  the 
SWAP_DBR  portion  of  GETWORK  to  multiplex  the  MHO_IMAGE  onto 
the  MMU  hardware  and  this  can  be  accomplished  by  changing 
about  a  dozen  lines  of  the  existing  code. 

B.  follow  on  work 

Although  the  monitor  appears  to  execute  correctly,  it 
has  not  been  rigorously  tested.  Before  higher  levels  of  the 
system  are  added,  it  is  essential  that  the  monitor  be  highly 
reliable.  Therefore  a  formal  test  and  evaluation  plan 
should  be  developed. 

An  automated  system  generation  and  initialization  me¬ 
chanism  is  also  required  if  the  monitor  to  be  is  a  useful 
tool  in  the  development  of  higher  levels  of  the  design. 

Once  the  monitor  has  been  proven  reliable  and  can  be  ( 
loaded  easily,  work  on  the  implementation  of  the  Memory  Man¬ 
ager  kernel  process  and  the  remainder  of  the  kernel  can  con¬ 
tinue  . 
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PART  E 


IMPLEMENTATION  OF  SEGMENT  MANAGEMENT  FOE  A 
SECURE  ARCHIVAL  STORAGE  SYSTEM 


his  section  contains  excerpts  from 
chool  MS  Thesis  by  J.  T.  Wells  [20]. 
excerpts  are: 


a  Naval  Postgraduate 
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SEGMENT  MANAGEMENT  FUNCTIONS 
SEGMENT  MANAGER 

NON "DISCRETIONARY  SECURITY  MODULE 
MEMORY  MANAGER 

SUMMARY  from  chapter 

SEGMENT  MANAGEMENT  IMPLEMENTATION  from  Chapter 

CONCLUSIONS  AND  FOLLOW  ON  WORK  from  Chapter 


I 


II 

III 

IV 


Minor  changes  have  been  made  for  integration  into  this  report 


Chapter  XVI 
INTBODQCTION 

This  thesis  addresses  the  implementation  of  the  segment 
management  functions  of  an  operating  system  known  as  the  Se¬ 
cure  Archival  Storage  System  or  SASS.  This  system,  with  full 
implementation,  will  provide:  (1)  multilevel  secure  access 
to  information  (files)  stored  in  a  "data  warehouse"  for  a 
network  of  multiple  host  computers,  and  (2)  controlled  data 
sharing  among  authorized  users.  The  correct  performance  of 
both  of  these  features  is  directly  dependent  upon  the  prop¬ 
er  implementation  of  the  segment  management  functions  ad¬ 
dressed  in  this  thesis.  The  issue  of  access  to  sensitive  in¬ 
formation  is  addressed  by  the  Non-Discrecionar y  Security 
Module,  which  mediates  all  non- discretionar y  access  to  in¬ 
formation.  Sharing  of  information  is  accomplished  chiefly 
through  the  properties  of  segmentation,  the  SASS  memory  man¬ 
agement  scheme  that  is  supported  by  the  Memory  Manager  Mo¬ 
dule  and  the  Segment  Manager  Module.  The  implementation  of 
segment  management  for  SASS  is  thus  integral  to  the  attain¬ 
ment  of  the  two  key  goals  that  SASS  was  designed  to  achieve. 
This  implementation  addresses  the  Non-Discre tionary  Securi¬ 
ty,  Distributed  Memory  Manager  (the  interface  to  the  Memory 
Manager  Process),  and  Segment  Manager  modules. 
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Chapter  XVII 

SEGMENT  MANAGEMENT  FUNCTIONS 

A.  SEGMENT  MANAGER 
1.  Function 

The  Segment  Manager  is  the  focal  point  of  the  segment 
management  function.  Using  the  per-process  Known  Segment  Ta¬ 
ble  as  its  database  and  the  Memory  Manager  and  Non-Discre- 
tionary  Security  Module  in  strongly  supportive  roles,  it  is 
responsible  for  managing  the  segmented  virtual  memory  for  a 
process.  Its  role  ca.n  be  viewed  as  somewhat  intermediary  in 
nature  (viz.,  between  the  Supervisor  modules  and  the  Memory 
Manager  modules) .  The  extended  instruction  set  created  in 
the  Segment  Manager  includes  the  following  instructions: 
CREATE_3EGMENT,  DELETE_S  EGMENT,  MAKE_KNC  WN ,  TERMINATE 
S M_SW AP_IN ,  and  SM_SWAP_OOT  (cote  that  the  names  for  SWAP_IN 
and  SWAP_OUT  have  been  modified  by  preceding  each  with  SM„; 
this  is  strictly  for  clarity  Decause  the  Memory  Manager  also 
creates  two  instructions  called  StfAP_IN  and  SWAP_G(JT)  . 
These  instructions  are  invoked  by  the  Supervisor  domain  of 
the  process  (viz.  ,  calls  are  made  from  the  Supervisor  domain 
via  the  Gatekeeper  to  the  Segment  Manager  in  the  Kernel  do¬ 
main)  to  provide  SASS  support  to  the  Host. 
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In  general ,  when  the  Segment  Manager  receives  these 
calls,  it  performs  certain  checks  to  ensure  the  validity  and 
security  compliance  (when  required)  of  the  request  (call) . 
These  checks  are  performed  using  its  own  database  (the  KST) 
and  by  calls  to  the  Non-Discretionary  Security  Module  (when 
required)  ♦  The  Segment  Manager  invokes  one  of  six  Memory 
Manager  (more  specifically,  the  Distributed  Memory  Manager 
Module)  created  instructions.  These  instructions  include: 
MM_C3EATE_ENTEY ,  MM_DELETE_ENTBY ,  MM_ACTIVATE, 
MM_DE ACTIVATE ,  MM_5WAP_IN,  and  MM_SWAP_OUT.  These  invoked 
instructions  (procedures)  in  turn  perform  interprocess  com- 
munciations  with  the  non-distributed  memory  manager  process 
(where  actual  memory  management  functions  are  accomplished) . 
These  interprocess  invocations  and  returns  are  accomplished 
through  the  use  of  the  IPC  primitives  Signal  and  Wait.  The 
Segment  Manager  returns  the  required  arguments  to  the  Super¬ 
visor  by  value  (as  passed  back  to  it  by  the  Memory  Manager 
and/or  determined  within  itself) .  The  Segment  Manager  per¬ 
forms  actual  segment  number  assignment  when  a  segment  is 
made  known  to  a  process*  address  space.  It  also  perforins 
any  further  database  (KST)  updating  as  may  be  required. 

2.  Database 

The  Known  Segment  Table  (KST)  is  the  database  used  to 
manage  segments.  The  KST  is  described  in  its  tabular  form 
and  PLZ/SYS  structured  representation  in  Figure  41.  There 
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are  several  basic  and  pertinent  facts  to  be  noted  of  the 
KST : 

1.  It  is  a  process  local  database;  that  is,  each  process 
has  its  own  KST. 

2.  The  KST  is  indexed  by  segment  numoer;  each  record  of 
the  KST  consists  of  a  set  of  fields  (description  in¬ 
formation)  regarding  a  particular  segment. 

3.  Entering  information  into  the  fields  of  a  segment  is 
called  "making  a  segment  known".  This  simply  refers 
to  adding  a  segment  to  a  process'  address  space 
(viz.,  making  a  segment  accessible  to  a  process). 

4.  In  5ASS,  a  correspondence  exists  between  making  a 
segment  "known"  and  making  a  segment  "active";  i.e., 
when  a  segment  is  added  to  the  address  space  of  a 
process,  this  action  results  in  an  entry  in  the  KST 
(making  "known")  by  the  Segment  Manager  and  an  entry 
in  the  Global  Active  Segment  Table  (G_ AST)  by  the  Me¬ 
mory  Manager  process  (making  it  "active") .  The  G_AST 
will  be  described  later  in  this  chapter. 

A  proper  description  of  the  structure  and  fields  of  the  KST 
is  necessary  at  this  point.  Using  the  representation  of  the 
PLZ/SYS  language  structure,  the  KST  is  described  as  an  array 
of  records  of  fields  of  varying  types.  The  fields  are  de¬ 
scribed  separately  below.  Although  the  KST  index  is  not  in 
itself  a  field  in  the  record,  it  does  perform  a  rather  sig¬ 
nificant  role.  The  KST  index  is  an  integer  closely  related 
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to  the  segment  number  of  the  segment  described  in  that  KSI 
entry  (viz.,  it  is  the  subscript  into  tne  array  of  records). 
This  segment  number  also  corresponds  to  the  MMU  descriptor 
register  (number)  for  that  segment. 

The  MM_Mandle  is  the  first  field  in  a  KST  record.  The 
MM_Handle  is  a  system  wide  unique  number  that  is  assigned  to 
each  segment  with  an  entry  in  the  G_AST  (viz.  ,  every  active 
segment)  .  This  "handle"  is  the  instrument  of  controlled  sin¬ 
gle  copy  sharing  of  information  (segments) .  It  allows  a  seg¬ 
ment  to  exist  under  one  unique  handle  but  be  accessible  in 
the  address  space  of  more  than  one  process  (with  different 
segment  numbers  in  each  address  space).  The  MM_Handle  is  re- 
turned  to  the  Segment  Manager  by  the  Memory  Manager  during 
the  execution  of  the  Make_Known  instruction. 

The  Size  field  is  an  integer  value  (of  language  struc¬ 
ture  type  "word")  which  represents  the  number  of  256  byte 
blocks  composing  a  segment. 

The  Access_Mode  field  is  used  to  describe  the  process' 
access  to  the  segment  (i.e.,  null  or  read  and/or  write). 

The  In_Core  field  is  used  to  indicate  if  the  segment  is 
or  is  not  in  main  memory  (i.e.,  this  field  is  a  flag  or 
true/false  boolean  switch) . 

The  Class  field  is  a  long  word  field  used  to  represent 
the  degree  of  information  sensitivity  (viz.,  access  class) 
assigned  to  the  segment.  This  field  (for  example)  would  be 
used  to  numerically  describe  a  classification  label  (as  de¬ 
scribed  above) . 
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Figure  41:  Known  Segment  Table 
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The  Mentor_Seg_Nr  field  is  a  number  representing  the 
segment  number  of  a  segment's  parent  or  "mentor"  segment. 
Its  importance  will  discussed  shortly. 

The  Entry_Nr  field  is  a  number  representing  a  segment's 
index  number  into  its  parent  or  mentor  segment's  Alias  Table 
(not  yet  discussed)  . 

The  Alias  Table  is  a  Memory  Manager  database  and  will  be 
described  later.  The  aliasing  scheme  provided  via  the  alias 
tables  is  used  to  prevent  passing  system  wide  information 
out  of  the  Kernel  (i.e.,  the  Unique_ID  of  a  segment) .  The 
"alias"  of  a  segment  is  the  concatenation  of  the  Men- 
tor_Seg_Nr  wirh  the  segment's  Entry_Nr  (index)  into  the  men¬ 
tor  segment's  Alias  Table.  It  is  clear  that  the  last  two 
fields  of  a  KST  record  are  the  "alias"  of  that  segment. 

B.  NON- disc region ary  security  module 

The  key  in  protection  of  secure  information  using  inter¬ 
nal  controls  was  identified  as  the  security  kernel  concept. 
The  basic  idea  within  this  concept  is  to  prove  the  hardware:' 
part  of  the  Kernel  correct  and,  similarly,  to  keep  the  soft¬ 
ware  part  small  enough  so  that  proving  it  correct  is  feasi¬ 
ble.  A  central  component  of  the  kernel  software  is  the 
Non-Discretionary  Security  Module  (hereafter  referred  to  as 
the  NDS  Module) .  The  NDS  Module  is  concerned  only  with  the 

1 

non-discretionary  aspect  of  the  security  policy  in  effect; 
since  the  discretionary  aspect  is  subservient  in  nature  to 
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the  non- discretionary  aspect,  it  is  tnen  sufficient  that  the 
Kernel  contain  only  the  software  representing  the  non-dis- 
cretionary  aspect  of  the  security  policy.  The  discretionary 
security  is  provided  outside  the  kernel  in  the  SASS  supervi¬ 
sor.  Every  attempt  to  access  information  must  result  in  an 
invocation  of  the  NDS  Module. 

The  function  of  the  NDS  Module  is  to  compare  two  classi¬ 
fications  (viz.  ,  compare  two  labels)  ,  make  a  decision  as  to 
their  relationship  (i.e.,  =,>,<#{),  and  return  a  true/false 
interpretive  answer  relative  to  the  query  of  the  calling 
procedure.  The  mechanism  used  as  a  basis  is  the  lattice  mo¬ 
del  abstraction  previously  discussed.  The  NDS  Module  does 
not  require  a  database  since  the  labels  it  compares  are 
stored  in  (passed  from)  other  Kernel  databases. 

C.  MEMORY  MANAGER 
1 .  Function 

The  Memory  Manager  process  is  the  only  component  of  the 
non-distributed  kernel.  It  is  responsible  for  managing  the 
real  memory  resources  of  the  system  —  main  (local  and  glo¬ 
bal)  memory  and  secondary  storage.  It  is  tasked  by  ether 
processes  within  the  Kernel  domain  (via  Signal  and  Wait)  to 
perform  memory  management  functions.  Ihis  thesis  will  ad¬ 
dress  the  Memory  Manager  in  terms  of  two  components:  (1)  the 
Memory  Manager  Process  (also  called  the  nona istributed  ker¬ 
nel  and  the  Memory  Manager  Module),  and  (2)  the  distributed 
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Memory  Manager  (also  called  the  Distributed  Memory  Manager 
Module)  .  The  former  is  the  "true"  memory  manager  while  the 
latter  is  the  interface  with  other  processes,  that  is,  it 
resolves  the  issue  of  interprocess  communication  with  the 
"true"  memory  manager. 

The  Distributed  Memory  Manager  Module  creates  the  fol¬ 
lowing  extended  instruction  set:  MM_CHEArE_ENTRY, 
MM_DELETE_ ENTRY ,  MM_ACTIV ATE,  MM_DE ACTI V ATE ,  MM_SWAP_IN,  and 
MM_SWAP_OCJT.  The  instructions  form  the  mechanism  of  communi¬ 
cation  between  the  Segment  Manager  of  a  process  and  a  memory 
manager  process  (where  the  actual  memory  management  func¬ 
tions  are  performed) .  The  Memory  Manager  Process  instruction 
set  corresponds  one  to  one  with  that  of  the  Distributed  Me¬ 
mory  Manager;  the  set  consists  of:  CREAIE_ENTRY, 
DSLSTE_ENTRY,  ACTIVATE,  DEACTIVATE,  SWAP_IN,  and  SWAPJJUT. 
The  basic  functions  performed  by  the  Memory  manager  are  al- 
location/deallocation  of  global  and  local  memory  and  of  sec¬ 
ondary  storage,  and  segment  transfers  from  local  to  global 
memory  (and  vice-versa)  and  from  secondary  storage  to  main 
memory  (and  vice-versa)  . 

2.  Databases 

A  detailed  and  descriptive  discussion  of  the  Memory  Man¬ 
ager  databases  is  presented  in  the  work  of  Gary  and  Moore 
[5],  and  the  reader  may  refer  to  it  for  memory  manager  data¬ 
base  details.  This  thesis  addresses  the  implementation  of 
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the  distributed  Memory  Manager  but  not  the  Memory  Manager 
Process,  thus  brief  descriptions  are  provided  of  the  lat¬ 
ter's  databases. 

The  Global  Active  Segment  Table  (G_AST)  is  a  system  wide 
(i.e. ,  shared  by  all  memory  manager  processes)  database  used 
to  manage  all  active  segments.  A  lock/unlock  mechanism  is 
used  to  prevent  race  conditions  from  occurring.  The  distri¬ 
buted  memory  manager  of  the  signalling  process  locks  the 
G_AST  before  it  signals  the  memory  manager  process. 

The  Local  Active  Segment  Table  (L_A3T)  is  a  processor 
local  database  which  contains  an  entry  for  each  segment  ac¬ 
tive  in  a  process  currently  loaded  in  local  memory. 

The  Alias  Taole  is  a  system  wide  database  associated 
with  each  nonleaf  segment  in  the  Kernel.  It  is  a  product  of 
the  aliasing  scheme  used  to  prevent  passing  system  wide  in¬ 
formation  out  of  the  Kernel.  The  ali.as  table  header  (provid¬ 
ed  for  file  system  reconstruction  after  system  crashes)  has 
two  pointers,  one  linking  the  alias  table  to  its  associated 
segment,  the  other  linking  the  alias  table  to  the  mentor 
segment's  alias  table.  The  fields  in  the  alias  taole  are 
Cnique_ID,  Size,  Class,  ?age_Table_Loc,  and  Aiias_Table_Loc. 
The  index  into  the  alias  table  is  Entry_No. 

The  Memory  Management  Unit  Image  (MMU_Image,  Figure  42) 
i.s  a  processor  local  database  indexed  by  D8B_No  (viz.,  for 
each  D3R_No  there  is  a  MMU_Image  record,  with  each  record 
containing  a  software  image  of  the  segment  descriptor  regis- 


163 


ters  of  the  hardware  MMU) .  The  MMU_Image  is  an  exact  image 
of  the  MMU.  Each  record  is  indexed  by  Segment_No  (segment 
number)  and  each  Segment_No  entry  contains  three  fields.  The 
3ase_Addr  field  contains  the  segment's  base  address  in  memo¬ 
ry.  The  Limit  field  contains  the  number  of  blocks  of  conti¬ 
guous  storage  for  the  segment  (zero  indicates  one  block) . 
The  Attributes  field  contains  8  flags  including  5  which  re¬ 
late  to  the  memory  manager.  The  Blks_Used  field  and  the 
Max_Blks  (available)  fields  are  per  record  (not  per  segment 
entry)  and  are  used  in  the  management  of 
each  process'  virtual  core. 

The  Memory  Bit  Maps  (Disk_Bi  t_Map,  Glo- 

bal_Memory_Bit_Map,  and  Local_Memory_8it_Map)  are  memory 
block  usage  maps  that  use  true/false  flags  (bits)  to  indi¬ 
cate  the  use  or  availability  of  storage  blocks. 

The  only  database  in  the  Distributed  Memory  Manager  is 
the  Memory  Manager  CPU  Table  (Figure  43)  .  It  is  an  array  of 
memory  manager  VP_ID's  (MM_VP_ID)  indexed  by  CPU  number. 
This  table  enables  a  signalling  process  to  identify  the  ap¬ 
propriate  memory  manager  process  (virtual  processor)  to  sig¬ 
nal. 
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Figure  43:  Memory  Manager-CPU  Taole 

D .  SUMMARY 

The  segment  management  functions  and  key  related  con¬ 
cepts  {such  as  segmentation)  were  discussed  in  this  chapter. 
The  importance  of  segmentation  to  data  sharing  and  informa¬ 
tion  security  was  emphasized  as  were  key  information  securi¬ 
ty  concepts.  With  this  background,  the  implementation  of 
segment  management  and  a  non-discr etionary  security  policy 
will  be  described  in  the  following  chapter. 
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Chapter  X7III 

S2GM2NT  MANAGEMENT  IMPLEMENTATION 
The  i op  1 e me at  at i on  or  segment  management  functions  and  a 
non-disc retro nary  security  policy  is  presented  in  this  chap¬ 
ter.  Paramount  to  this  implementation  were  several  key  is¬ 
sues  that  arfected  the  implementation.  These  issues  are  dis¬ 
cussed  first .  The  implementation  is  discussed  in  terms  of 
the  Segment  Manager,  Non- Discret ionary  Security  (NDS ) ,  and 
Distributed  Memory  Manager  modules. 

A.  IMPLEMENTATION  ISSUES 

Segment  management  for  the  SA5S  was  provided  through  the  im¬ 
plementation  of  the  Segment  Manager  Module,  the  NDS  Module, 
and  the  Distrinuted  Memory  Manager  Module.  Additionally, 
since  a  de mcnstration/testbed  was  integral  to  the  testing 
and  verification  of  the  implementation,  it  was  necessary  to 
complete  other  supportive  tasks.  Beitz  [12]  provided  a  de¬ 
monstration  of  the  operation  of  the  Inner  Traffic  Controller 
primitives  SIGNAL  and  SAIT  {for  interprocess  communica¬ 
tion).  Integral  to  this  demonstration  was  the  correct  per¬ 
formance  of  the  Inner  Traffic  Controller  7?  scheduling  me¬ 
chanism  and  a  "stub"  of  the  Traffic  Controller  and  its 
process  scheduling  mechanism  (the  TC  support  and  use  of  the 
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mechanism  of 


eventcounts  and  sequencers  was  not  a  part  of 
the  demonstration) .  The  Segment  management  demonstration 
(hereafter  referred  to  as  "Seg_Mgr. Demo")  was  "built  on  top 
of"  Reitz'  ITC  synchronization  primitive  demonstration 
(hereafter  referred  to  as  "Sync.  Demo") .  Thus,  an  immediate 
issue  was  to  resolve  the  feasibility  of  adding  on  to 
Sync. Demo  and  also  to  refine  the  present  design  of  the  Sync. 
Demo  to  facilitate  its  integration  into  the  Seg_Hgr.Demo. 
One  aspect  of  this  effort  was  in  resolving  the  problem  of 
how  to  pass  (i.e.,  in  interprocess  communication)  a  larger 
message. 

1 •  Interprocess  Messages 

The  Sync. Demo  passed  "word"  (16  bit)  messages.  To  pro¬ 
vide  the  mechanism  for  the  distributed  memory  manager  to  t 
signal  the  memory  manager  process  with  a  command  function 
identification  code  and  the  arguments  needed  to  perform  that 
function  (e.g.,  CREATE-ENTEY  and  its  input  arguments),  a 
message  size  of  at  least  eight  words  (16  bytes)  was  neces¬ 
sary.  An  obvious  answer  was  to  signal  with  an  array  of 
eight  words  as  the  message.  PLZ/SYS,  however,  does  not  al¬ 
low  passing  arrays  in  its  procedure  calls  (a  procedure  call 
is  analogous  to  a  subroutine  call).  Another  alternative  was 
to  signal  with  a  pointer  to  the  array  of  words,  since 
PLZ/SYS  does  allow  passing  pointers  in  procedure  calls  (thus 
the  message  would  be  a  pointer  to  the  real  message) .  This, 
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however ,  would  be  invalid  in  the  segmented  implementation 
(on  the  Z6000  segmented  microprocessor)  since  identical  seg¬ 
ment  numbers  in  different  processes  may  not  refer  to  identi¬ 
cal  segments.  For  example,  a  pointer  in  a  process  (e.g., 
file  management)  points  to  an  array  (i.e.,  provides  its  ad¬ 
dress)  by  segment  number  and  offset;  passing  this  pointer  to 
another  process  (e.g.,  memory  manager)  would  provide  this 
same  segment  number  and  offset  which,  of  course,  may  be  a 
different  object  in  the  second  process's  address  space). 

Another  alternative  considered  was  that  of  a  shared 
"Mailbox"  segment  with  an  associated  eventcount  acted  on  by 
the  Kernel  Inner  Traffic  Controller  primitives 
TICKET, ADVA NCE  and  AWAIT.  A  design  for  using  this  concept 
in  the  supervisor  ring  is  provided  by  Parks  [9].  This  al¬ 
ternative  was  not  deeply  considered  since  these  primitives 
are  not  included  in  the  current  Inner  Traffic  Controller. 

The  method  ultimately  used  to  signal  the  new  length  mes¬ 
sages  is  based  on  the  fact  that  the  ITC  is  in  both  the  sig¬ 
nalling  and  the  receiving  (memory  manager)  processes'  ad¬ 
dress  space.  The  message  is  loaded  into  an  array  in  process 
#1  and  a  pointer  to  the  array  is  passed  in  the  call  SIGNAL; 
the  VPT,  the  ITC's  database,  is  then  updated  by  (using  the 
pointer)  putting  the  message  into  its  MSG_Q  section.  The 
message  is  retrieved  by  process  #2  by  execution  of  Reitz' 
WAIT  primitive  with  only  one  refinement.  That  refinement  is 
for  the  "waiting"  process  to  provide  as  an  argument  (in  the 
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WAIT  primitive)  a  pointer  to  its  own  message  array  so  that 
the  message  in  the  VPT  can  be  copied  to  it.  This  refinement 
provides  for  passing  a  long  message  essentially  "by  value" 
between  processes. 


2.  Structures  as  Arguments 

Another  issue  concerned  the  use  of  pointers  in  the  im¬ 
plementation  of  segment  management.  This  necessary  "evil" 
is  a  result  of  the  need  to  pass  linguistically  "complex" 
data  types  in  procedure  calls.  Complex  types  refer  to  array 
and  record  structures  in  PLZ/SIS  (as  opposed  to  the  "simple" 
types — byte,  word,  integer,  short-integer,  long,  and  poin¬ 
ter).  In  managing  databases  (e.  g.  ,  KSI,  5_AST)  which  con¬ 
sist  of  arrays  of  records  (which  in  turn  contain  records 
and/or  arrays) ,  it  was  frequently  necessary  to  reference 
data  as  an  array  or  record.  Within  a  process,  the. use  of 
pointers  was  not  a  problem  (i.e.,  not  a  proolem  such  as 
would  be  encountered  in  IPC  passing  of  pointers) . 

3.  Reentrant  Code 

The  issue  of  code  reentrancy  was  addressed  at  the  assem¬ 
bly  language  level  through  the  use  of  a  stack  segment  anc 
registers  for  storage  of  local  variables.  PLZ/SYS  (high 
level  language)  does  not  address  reentrant  procedures  anc 
thus  the  segment  management  high  level  code  is  not  automati¬ 
cally  reentrant.  The  problem  of  reentrancy  can  be  seen  by 
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looking  at  a  shared  procedure  that  is  not  reentrant;  such  a 
procedure  has  storage  for  its  variables  allocated  statically 
in  memory.  Suppose  a  procedure  (e.g.,  in  the  Kernel)  can  be 
activated  by  more  than  one  process.  While  the  procedure  is 
executing  in  one  process,  a  process  switch  occurs  (e.g.,  to 
wait  for  a  disk  transfer)  and  its  execution  is  suspended. 
The  second  process  is  activated,  and  while  it  is  running  it 
invokes  the  procedure.  While  the  procedure  is  executing  for 
the  second  process  it  uses  the  same  storage  space  for  varia¬ 
bles  as  it  did  when  executing  for  the  first  process.  Eventu¬ 
ally,  it  relinquishes  the  processor.  However,  when  the 
procedure  resumes  its  execution  for  the  first  process,  the 
variable  values  that  were  in  use  by  it  originally  have  been 
changed  during  its  execution  in  the  second  process.  Thus, 
incorrect  results  are  now  inevitable. 

4 .  Process  Structure  of  the  Memory  Manager 

References  to  the  "Memory  Manager"  in  past  works  have 
generally  meant,  the  memory  manager  process  (non-distributed 
kernel) .  This  work  references  two  distinct  components  of 
the  "memory  manager  module".  The  Distributed  Memory  Manager 
is  an  interface  provided  to  the  Memory  Manager  Process.  It 
is,  in  fact,  distributed  in  the  address  space  of  each  Super¬ 
visor  process.  In  contrast,  the  Memory  Manager  Process 
clearly  is  not  distributed  and  its  address  space  is  con¬ 
tained  entirely  in  the  Kernel. 
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5. 


£§Er££Qcess  Known  Segment  l^ble 
Another  key  issue  was  that  of  the  per  process  Segment 
Manager  database,  the  KST .  Since  each  process  has  its  own 
KST,  it  cannot  be  linked  to  the  (shared)  segment  manager 
procedures.  To  implement  the  KST  as  a  per  process  database, 
it  was  convenient  to  establish,  by  convention,  a  KST  segment 
number  that  is  consistent  from  process  to  process.  That 
segment  in  each  process  is  the  KST  segment  for  that  process. 
Implementation  is  then  accomplished  by  using  the  segment 
number  to  construct  a  pointer  to  the  base  of  the  appropriate 
KST.  It  is  then  easy  to  calculate  an  appropriate  offset  to 
index  any  desired  entry  in  the  KST  data. 

6.  DBB  Handle 

In  Reitz's  implementation  of  the  multilevel  scheduler 
and  the  IPC  primitives,  references  to  "DBR"  (descriptor  base 
register)  are  references  to  an  address.  That  address  value 
represents  a  pointer  to  an  MMU_I MAGE  record  containing  the 
list  of  descriptors  for  segments  in  the  process  address 
space.  Gary  and  Moore  [5]  reference  a  "DBR_NO"  that  is  es¬ 
sentially  a  handle  used  within  the  memory  manager  as  an  in¬ 
dex  within  the  MMU_IMAGE  to  a  particular  MMU  record.  The 
base  address  of  the  HMD  record  indexed  by  DBH_NO  is  then 
equivalent  to  the  concept  of  DBR  value  used  in  Reitz'  work. 
The  effect  of  this  inconsistency  on  the  segment  management 
implementation  was  minor  and  will  be  further  discussed  later 
in  this  chapter. 
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B.  SEGMENT  MANAGER  HOPPLE 

The  Segment  Manager  Module  consists  of  six  procedures 
representing  the  six  extended  instructions  it  provides. 
These  are  based  on  the  design  of  Coleman  £2].  Only  calls 
from  external  to  the  Kernel  (via  the  Gate  Keeper)  may  be 
made  to  the  segment  Manager  (per  the  loop-free  structure  of 
the  SASS)  .  The  normal  sequence  of  invocation  of  the  Segment 
Manager  functions  to  allow  referencing  a  segment  is:  (1) 
CREATE_SEGMENT — allocate  secondary  storage  for  the  segment 
and  update  the  mentor  segment's  Alias  Table,  (2) 
MAKE_KNOWN — add  the  segment  to  the  process  address  space 
(segment  number  is  assigned) ,  (3)  SWAP_IN — move  the  segment 
from  secondary  storage  into  the  process's  main  memory.  The 
normal  sequence  of  invocation  to  "undo1'  the  above  is:  (1) 
SWAP_OOT — move  the  segment  from  main  memory  to  secondary 
storage,  (2)  TERMINATE — remove  the  segment  from  the  pro¬ 
cess's  address  space,  (3)  DELETE_SEGMENI — deallocate  secon¬ 
dary  storage  and  remove  the  appropriate  entry  from  the  alias 
table  of  its  mentor  segment.  The  six  Supervisor  entries 
into  the  Segment  Manager  (viz.,  the  six  extended  instruc¬ 
tions)  will  be  discussed  individually  below.  The  PLZ/ASM 
listings  for  the  Segment  Manager  are  in  Appendix  H. 
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Create  a  Segment 

The  function  that  creates  a  segment  (i.e.,  adds  a  new 
segment  to  the  SASS)  is  CR EAT 2_ SEGUE NT.  This  function  vali¬ 
dates  the  correctness  of  the  Supervisor  call  by  checking  the 
parameters  and  making  certain  security  checks.  The  distri¬ 
buted  memory  manager  is  then  called  to  accomplish  interpro¬ 
cess  communication  with  the  Memory  Manager  Process,  where 
segment  creation  is  realized  through  secondary  storage  allo¬ 
cation  and  alias  table  updating. 

C  RE  ATE_  SEGMENT  is  passed  as  arguments:  (1)  Men- 

tor_Seg_No-- the  segment  number  of  the  mentor  segment  of  the 
segment  to  be  created,  (2)  Entry_No — the  desired  entry  num¬ 
ber  in  the  alias  table  of  the  mentor  segment,  (3)  Class — the 
access  class  (label)  of  the  segment  to  be  created,  and  (4) 
Size — the  desired  size  of  the  segment  (in  blocks  of  256 
bytes)  .  The  initial  check  is  to  verify  that  the  desired 
size  does  not  exceed  the  designed  maximum  segment  size.  If 
this  check  is  satisfactory,  a  conversion  of  the  Men- 
tor_Seg_No  to  a  KST  index  is  necessary.  This  is  because  the 
Kernel  segments  use  the  first  several  segment  numbers  avai¬ 
lable  but  do  not  have  entries  in  the  KST.  Thus  if  there 
were  10  Kernel  segments  and  a  system  segment  had  segment 
number  15,  then  its  index  in  the  KST  would  actually  be  5 
(i.e., the  Kernel  segments  would  use  numbers  0-9,  and  this 
segment  would  be  the  sixth  segment  in  the  KST  and  its  index 

i 

would  be  5) .  A  call  is  then  made  to  the  procedure 
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I TC_GET_S£G  _PTR  with  the  constant  KST_SEG_NO  passed  as  a 
parameter.  This  procedure  will  return  a  pointer  to  the  base 
of  this  process'  KST.  This  pointer  is  then  the  basis  for 
addressing  entries  m  the  KST.  The  next  check  is  to  see  if 
the  mentor  segment  is  known  (viz. ,  is  in  the  address  space 
of  the  process,  and  thus,  in  the  KST).  The  key  to  determin¬ 
ing  if  any  segment  is  known  is  the  mentor  segment  entry 
(M_SEG_No)  for  that  segment  in  the  KST.  If  not  known,  this 
entry  in  the  segment's  KST  record  will  be  filled  with  the 
constant  N0LL_SEG.  The  basis  for  checking  to  see  if  the 
segment's  mentor  segment  is  known  is  the  aliasing  scheme  im¬ 
plication  that  a  meaner  segment  must  be  known  before  a  seg¬ 
ment  can  be  created.  The  process  classification  must  next 
be  obtained  from  the  Traffic  Controller.  The  process  clas¬ 
sification  is  checked  to  ensure  that  it  is  equal  to  the 
classification  of  the  mentor  segment  since  write  access  to 
its  alias  table  is  needed  to  create  a  segment.  The  NDS  mo¬ 
dule's  CLASS_EQ  procedure  is  called  and  returns  a  code  of 
true  or  false.  The  last  check  is  the  compatibility  cneck  to 
ensure  that  the  classification  of  the  segment  to  be  created 
is  greater  than  or  equal  to  the  classification  of  the  mentor 
segment.  This  is  accomplished  by  calling  the  NDS  Module's 
CL ASS_GE  procedure  which  returns  a  code  of  true  or  false. 
If  any  of  these  checks  are  unsatisfactory,  an  appropriate 
error  code  is  generated  and  the  Segment  Manager  returns  to 
its  calling  point.  If  all  checks  are  satisfactory,  then  a 
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pointer  to  the  mentor  segment's  MM_Handle  array  is  derived 
(HPTR)  .  Note  that  in  the  current  memory  manager  design  [5] 
the  actual  MM_Handle  contents  are  a  (Jnigue_ID  (a  long  word, 
viz.,  two  words  concatenated) ,  and  an  Index_No  (index  into 
the  G_AST,  a  word) ;  thus  together  these  two  fields  are  a  to¬ 
tal  of  three  words.  Since  the  Segment  Manager  does  not  in¬ 
terpret  this  handle,  it  is  considered  a  three  word  array  at 
this  level.  For  this  reason,  the  entire  uninterpreted 
MM_Handle  array  will  be  passed  by  passing  its  pointer.  This 
pointer  and  Entry_No,  Size,  and  Class  are  then  passed  in  a 
call  to  the  distributed  memory  manager  procedure 
3M_CREATE_ENTRY .  This  procedure,  in  turn,  performs  IPC  with 
the  memory  manager  process  where  segment  creation  ultimately 
is  accomplished.  A  success  code  is  returned  in  an  IPC  mes¬ 
sage  from  the  memory  manager  process  via  the  distributed  me¬ 
mory  manager  to  the  C RE A TE_ SEGMENT  procedure  to  indicate 
success  or  failure  as  appropriate.  This  success  code  is 
checked  by  the  Segment  Manager  to  ensure  confinement  would 
not  be  violated  if  it  is  returned  to  the  calling  process' 
supervisor  domain.  Only  after  the  success  code  has  been  re¬ 
turned  can  the  action  of  segment  creation  be  considered  com¬ 
plete.  Segment  creation  does  not  imply  the  ability  to  re¬ 
ference  that  segment;  MAKE_KNOWN  will  accomplish  that. 
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Delete  a  Segment 

The  function  that  deletes  a  segment  (i.e. ,  deletes  a 
segment  from  SASS)  is  DELETE_SEGMENT .  Validation  of  parame¬ 
ters  and  security  checks  are  performed  here  similar  to  (but 
fewer  than)  the  CHEATE__SEGilENT  checks.  The  distributed  me¬ 
mory  manager  is  then  called  to  cause  XPC  with  the  memory 
manager  process,  where  segment  deletion  is  realized  through 
secondary  storage  deallocation  and  alias  table  entry  dele¬ 
tions.  DELETE_SEGMENT  is  passed  as  arguments:  (1)  Men- 
tor_Seq_No  and  (2)  Entry_No.  Conversion  of  the  Men- 
tor_Seg_No  to  a  KST  index  is  accomplished  first.  The 
pointer  to  the  base  of  the  KST  is  located  and  returned,  as 
before.  The  mentor  segment  is  checked  to  ensure  it  is 
known,  again,  by  verifying  that  its  own  H_SEG_No  (mentor 
segment  number)  entry  in  the  KST  is  not  the  NULL_SEG.  The 
process  classification  is  obtained  from  the  TC  and  checked 
(by  a  call  to  CLASS_EQ)  to  ensure  it  is  equal  to  the  mentor 
segment  classification,  since  deleting  an  entry  requires 
write  access  to  the  alias  table.  If  all  cnecks  are  satis¬ 
factory,  then  the  mentor  segment's  KK_Handle  pointer  is  der¬ 
ived.  This  pointer  and  the  mentor  segment  alias  table  entry 
number  are  passed  in  a  call  to  the  distributed  menory  manag¬ 
er  procedure  MM_DELETE_ENT3Y.  It  then  performs  IPC  with  the 
memory  manager  process  where  segment  deletion  is  accom¬ 
plished  and  a  success  code  is  returned  as  before. 
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3 •  Make  a  Segment  Known 

The  function  that  makes  a  segment  known  (i.e.,  adds  that 
segment  to  the  process'  address  space  by  assigning  a  segment 
number,  updating  the  KST,  and  causing  the  memory  manager 
process  to  "activate"  the  segment  (that  is,  add  it  to  the 
AST  ))  is  MAKE_KNOWN.  Making  a  segment  known  is  the  way  the 
Supervisor  declares  its  intention  to  use  a  segment. 
MAKE.KNOWN  is  passed  as  arguments:  (1)  Mentor_Seg_No ,  (2) 

Entry_No,  and  (3)  Acess_Desired  (e.g.,  write,  read,  or 
null)  .  It  returns  (1)  a  success  code,  (2)  the  access  al¬ 
lowed  to  the  segment,  and  (3)  the  segment  number.  Conver¬ 
sion  of  the  mentor  segment  number  to  a  KST  index,  finding 
the  KST  pointer,  and  verifying  that  the  mentor  segment  is 
known  occur  as  previously  discussed. 

There  are  three  basic  cases  that  may  occur  in  j 
MAKE_KNOWN:  (1)  the  segment  is  already  known  (has  an  entry 

in  the  KST)  ,  (2)  the  segment  is  not  known  and  there  is  a 

segment  number  available,  or  (3)  the  segment  is  not  known 
and  there  is  no  segment  number  available. 

A  search  is  made  of  the  KST  using  each  record's  (seg¬ 
ment's)  M_S EG_No  (mentor  segment  number)  and  Entry_Number 
fields  as  the  search  key.  If  these  two  fields  match  the  in¬ 
put  values  Mentor_Seg_No  and  Entry_No,  then  the  record  in¬ 
dexed  is  that  of  the  desired  segment;  thus  the  segment  to  be 
made  known  is  already  known.  In  this  case,  all  that  need  be 
done  is  to  return  the  success  code,  segment  number  (convert- 
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sd  from  the  index  by  adding  to  it  the  number  of  Kernel 
ments) ,  and  the  access  allowed  (egual  to  the  Access_Mode  en¬ 
try  in  the  KST  for  the  already  known  segment)  . 

During  the  search  of  the  KST,  the  M_SEG_No  field  is  also 
checked  to  see  if  it  contains  the  N(JLL_SEG  entry  (this  im¬ 
plies  that  the  segment  number  associated  with  the  record  is 
"available").  The  first  time  this  is  noted,  the  index  is 
saved.  Note  the  first  available  index  is  saved  since  it  is 
desired  to  assign  segment  numbers  at  the  "top"  of  the  KST  to 
keep  it  dense  there.  When  the  search  does  not  find  that  the 
segment  is  already  known,  the  index  for  the  available  seg¬ 
ment  number  is  retrieved  and  converted  to  segment  number  by 
adding  to  it  the  number  of  kernel  segments.  If  this  index 
is  the  N0LL_SEG  entry,  then  there  is  no  segment  number  avai¬ 
lable.  In  this  event,  the  success  code  is  set  to 
NO_SEG_AVAI L ,  the  segment  number  is  assigned  NCJLL_SEG,  and 
access  allowed  is  set  to  N  CLL_ACC ESS  (this  is  the  third  case 
mentioned) ,  If  the  index  is  not  equal  to  NU  LL_S EG  and  con¬ 
version  to  segment  number  has  occurred  then  the  Traffic 
Controller  is  called  to  provide  the  D3B_No  (descriptor  base 
register  number)  for  the  current  process.  The  DBH_No  is 
used  by  the  memory  manager  process  as  an  index  in  the 
MBD_Image  and  the  local  AST.  The  distributed  memory  manager 
procedure  mi_Ac tivate  is  called;  it  is  passed  the  DBR  num¬ 
ber,  the  pointer  to  the  mentor  segment's  MM_Handla  entry, 
the  mentor  segment  alias  table  Entry_No,  and  the  segment 
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number.  MM_Activate  performs  the  normal  interface  function 
(performs  I  PC  with  the  memory  manager  process  procedure  that 
updates  the  local  and  global  AST's)  and  also  updates  the  KST 
entry  for  the  new  segment's  MM_Handle  entry  (returned  from 
the  memory  manager  process) .  It  also  returns  to  the  Segment 
Manager  the  success  code,  the  segment  classification,  and 
the  segment  size  from  the  memory  manager  process.  If  the 
success  code  is  "succeeded"  then  the  issue  of  access  to  be 
granted  must  be  resolved.  The  process  classification  is  ob¬ 
tained  from  the  TC  and  passed  with  the  segment  classifica¬ 
tion  to  the  NDS  Module  procedure  CLASS_GE.  If  the 
CONDITION_CODE  returned  is  FALSE  then  access  allowed  is 
NULL_ACCESS,  the  segment  number  is  N(JLL_SEG,  and 
MM_DEACTIVATE  is  called  to  deactivate  the  segment.  An  appro¬ 
priate  error  code  is  returned.  If  it  is  greater  than  or 
equal  then  the  access  allowed  is  assigned  as  follows:  (1) 
the  two  classifications  are  compared  again — this  time  to  see 
if  equal;  (2)  If  they  are  equal,  then  the  access  allowed  is 
either  read  or  write  per  the  access  desired;  (3)  if  they  are 
not  equal  (i.e. ,  the  process  class  is  greater  than  the  seg¬ 
ment  class)  then  the  access  allowed  is  read.  Finally  the 
KST  entries  for  that  segment  number  (more  accurately  for  its 
index  in  the  KST)  are  filled  with  the  appropriate  informa¬ 
tion  (e.g.,  IN_CORE  is  false,  etc.).  If  the  success  code 
returned  from  the  memory  manager  process  via  the  distributed 
memory  manager  is  not  "succeeded",  then  the  segment  number 
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is  set  to  NULL_SEG  and  the  access  allowed  is  set  to 
NULL_ACCESS. 

4.  Make  a  Segment  Unknown  (Terminate) 

The  function  that  makes  a  segment  unknown  (i.e.,  removes 
that  segment  from  the  process'  address  space — by  updating 
the  KST  and  causing  the  memory  manager  process  to  "deacti¬ 
vate"  the  segment)  is  TEBMIMATE.  It  results  in  removal  of 
the  M_SEG_Mo  (mentor  segment  number)  entry  from  that  seg¬ 
ment's  KSI  record.  Terminate  is  passed  the  segment  number 
of  the  segment  to  be  terminated  as  an  argument.  It  returns 
a  success  code.  Conversion  of  the  segment  number  to  a  KST 
index,  finding  the  KST  pointer,  and  verifying  that  the  seg¬ 
ment  is  known  occurs  in  the  same  manner  as  previously  dis¬ 
cussed.  The  next  check  is  to  verify  that  the  segment  is  not 
still  leaded  in  the  process'  virtual  core  (viz.,  it  has  been 
"swapped-out " ) .  If  not,  an  error  code  is  returned  and  the 
user  must  cause  the  Segment  Manager  extended  instruction 
sa_SWAP_OUT  to  be  executed.  the  next  check  is  to  ensure 
that  the  user  is  not  attempting  to  terminate  a  Kernel  seg¬ 
ment.  The  first  several  segment  numbers  in  a  process'  ad¬ 
dress  space  will  be  used  by  Kernel  procedures  and  data 
(though  they  will  not  be  entries  in  the  KST) .  Thus  if  there 
were  10  Kernel  segments,  then  the  segment  number  to  be  ter¬ 
minated  must  be  greater  than  or  equal  to  #10  (since  the  Ker¬ 
nel  segments  used  #'s  0-9) .  Thus  a  check  is  made  to  ensure 
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that  the  segment  number  is  not  less  than  the  number  of  Ker¬ 
nel  segments;  otherwise  an  error  code  is  returned.  Next, 
the  segment  number  is  checked  to  ensure  that  it  is  not  lar¬ 
ger  than  the  maximum  segment  number  allowable  (if  so,  an  er¬ 
ror  code  is  returned) .  If  all  checks  are  satisfactory,  then 
the  segment's  MM_Handle  pointer  and  the  process  DBR_No  are 
obtained  (as  discussed  before)  and  passed  in  a  call  to  the 
MM_Deactiva te  procedure.  It  calls  the  memory  manager  pro¬ 
cess  procedure  DEACTIVATE  which  removes  or  updates  (as  ap¬ 
propriate)  the  entries  in  the  local  and  global  AST's. 

5 .  Swap  a  Segment  In 

The  function  that  swaps  a  segment  from  secondary  storage 
to  main  memory  (global  or  local)  is  SJ1_SHAP_IN.  It  is 
passed  the  segment  number  of  the  segment  to  be  swapped  in  as 
an  argument  and  returns  a  success  code.  Conversion  of  the  : 
segment  number  to  a  KST  index,  finding  the  KST  pointer,  and 
verifying  that  the  segment  number  is  known  are  accomplished 
as  previously  discussed.  If  the  check  is  satisfactory,  then 
the  segment's  MM_Handle  pointer  and  the  process  DBR  number 
are  obtained.  They  are  passed  with  the  segment's  access 
mode  (from  the  KST)  as  arguments  in  the  call  to  MM_SWAP_IN. 
It  performs  normal  interface  (IPC)  functions  and  returns  a 
success  code  from  the  memory  manager  process'  3WAP_IN  proce¬ 
dure  (where,  if  not  already  in  core,  allocation  of  main  me¬ 
mory  space  and  reading  the  segment  into  main  memory  occurs) . 
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If  the  success  code  is  "succeeded'*  then  the  segment's 
IN_CORE  entry  in  the  KST  is  updated  to  show  that  the  segment 
is  in  main  memory  for  this  process  (i. e. ,  the  entry  is  now 
"true")  . 

6.  Swap  a  Segment  Out 

The  function  that  swaps  a  segment  from  main  memory  to 
secondary  storage  is  SM_SWAP_OUT.  It  is  passed  the  segment 
number  of  the  segment  to  be  swapped  out  as  an  argument  and 
returns  a  success  code.  The  behavior  of  SM_SWAP_OUT  is  ex¬ 
actly  analogous  to  that  of  SM_S5tAP_IN  except  that  the  seg¬ 
ment's  KST  IN_CORE  entry  is  updated  to  reflect  that  the  seg¬ 
ment  has  been  removed  from  main  memory  for  this  process 
(i.e.,  the  new  entry  is  "false"). 

C.  NON- DISCRETIONARY  SECURITY  MODULE 

The  Non-Discret ionary  Security  Module  implements  the 
non-discretionary  security  policy  for  the  SASS.  The  NDS  mo¬ 
dule  contains  two  procedures:  CLASS_EQ  and  CLASS_GE;  both 
compare  two  labels  (classifications)  and  determine  if  their 
relationship  meets  that  of  the  procedure's  name  (i.e., 
equal,  or  greater  than  or  equal) .  Although  the  type  of 
checks  being  made  are,  in  fact,  compatibility  checks.  Simple 
Security  Condition  checks,  etc,  the  NDS  Module  does  not  re¬ 
cognize  or  need  to  recognize  this.  It  simply  uses  an  algor¬ 
ithm  to  determine  if  classification  #1  =  classification  #2 
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or  if  classification  #1  >=  classification  #2,  as  appropri¬ 
ate.  It  then  returns  a  condition  code  of  true  or  false  in 
accordance  with  the  particular  case.  The  earlier  discussion 
of  label  comparison  in  accordance  with  a  partially  ordered 
lattice  structure  is  relevant  in  discussing  the  NDS  Module's 
algorithm.  Consider  the  same  "totally  ordered"  relationship 
TS  >  S  >  C  >  U  of  levels  and  the  "disjoint"  relationship  Cy 
I  N  |  Nu  |  %  of  categories.  Comparison  of  levels  will  be 
numerical  comparisons  while  comparison  of  categories  will 
use  set  theory  comparison  as  a  basis.  If  TS  =  4,  S=3,  C=2r  0=1 
are  level  numerical  assignments,  then  the  totally  ordered 
relationship  is  maintained  (i.e.,  TS>S>C>U  is  still  true). 
Now  consider  the  categories  and  make  the  following  assign¬ 
ments:  Cy=1,  N=2,  Nu=4,  %=0.  Note  that  a  classification  may 
have  only  one  level  and  one  category  set  (the  category  set 
may  contain  several  categories) .  Consider  this  example: 

(TS,  Cy,N  .  The  level  is  TS  (=4)  .  The  category  is  the  set 

Cy,N  and  numerically  is  formed  by  performing  a  logical  OB 
with  the  categories  Cy  and  N.  Sixteen  bit  representation  of 
this  is: 

Cy  OR  N 

(0000  0000  0000  0001)  OR  (0000  0000  0000  0010) 

=  0000  0000  0000  0011  =  Cy,N 

If  (TS,  Cy ,  N  )  is  considered  label  #1  and  (S,  N  )  as  label 
#2  then  a  comparison  of  the  two  labels  would  be: 

(1)  Compare  level  #1  with  level  #2  —  4  >  3? 

Clearly,  the  answer  is  yes. 
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(2)  Compare  category  #1  with  category  #2  —  is 
(0000  0000  0000  0011)  a  superset  of 
(0000  0000  0000  0010) ,  or  more  clearly 
is  the  latter  a  subset  of  the  former? 

The  answer  is  yes,  and  one  way  to  show  that  is  true  is 
by  performing  a  logical  OR  of  category  #1  with  category  #2 
and  comparing  the  result  to  category  #1.  If  the  result  of 
the  OR  operation  eguals  category  #1  then  category  #1  is  a 
superset  (not  necessarily  proper)  of  category  #2.  Since  us¬ 
age  of  the  term  subset  is  more  freguent  than  that  of  super¬ 
set,  this  relationship  will  typically  be  stated  as  "category 
*2  is  a  subset  of  category  #1.  To  illustrate  the  above; 

Cy,N  OR  N  ; 

(0000  0000  0000  0011)  OR  (0000  0000  0000  0010) 

=  0000  0000  0000  0011  =  category  #1. 

This  means  ,  in  this  example,  that  category  #2  is  a  sub¬ 
set  (not  necessarily  proper)  of  category  <1.  Since  level  #1 

>  level  #2  and  category  #2  subset  category  31  then  label  #1 

>  label  i2.  Thus,  a  call  to  the  CLASS_2Q  procedure  with 
these  two  labels  as  the  input  classifications  would  return  a 
condition  code  of  false  while  CLASS„GE  would  return  true. 
The  decision  to  have  the  classifications  as  long  word  (32 
bits)  supports  the  requirement  of  some  DoD  specifications 
for  eight  levels  and  sixteen  categories.  This  module  uses 
sixteen  bits  for  the  level  and  sixteen  bits  for  the  catego¬ 
ry.  Appendix  I  is  the  PLZ/ASM  listings  for  the  NDS  Module. 
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1 .  Egjjal  Classification  Check 

The  CLASS_EQ  procedure  performs  comparison  of  two  clas¬ 
sifications  (labels)  and  returns  a  condition  code  of  true  if 
they  are  equal  (an  exact  match  of  the  two  long  words  bit  per 
bit)  or  false  if  they  are  not. 

2.  Gre§ter  or  Eguai  Classification  Check 

The  CLASS_GE  procedure  performs  comparison  of  two  clas¬ 
sifications  (labels)  and  returns  a  condition  code  true  if 
classif ication  #1  is  greater  than  or  equal  to  classification 
#2  or  a  condition  code  of  false  otherwise.  For  classifica¬ 
tion  #1  to  be  greater  than  or  equal  to  classification  #2, 
the  following  must  be  true:  (1)  level  #1  >=  level  #2  (deter¬ 
mine  this  by  simple  numerical  comparison  of  values)  and  (2) 
category  #2  subset  category  #1  (determine  this  by  performing 
a  logical  OR  with  the  categories  and  comparing  the  result  to 
category  #1  --  if  they  are  equal  then  category  #2  is  a  sub¬ 
set  of  category  #1)  . 

Since  PL2/SIS  allows  passing  only  "simple"  types  in 
calls,  the  labels  were  passed  as  long  words  (as  opposed  to 
each  being  word  arrays  of  length  two) .  An  access  class  label 
is  never  interpreted  outside  the  NDS  Module.  However,  with¬ 
in  the  NDS  Module  it  is  necessary  to  address  the  classifica¬ 
tion's  components  separately  (viz.,  level  and  category). 
Thus,  an  "overlay"  of  the  logical  view  of  the  classif ication 
was  created.  This  overlay  was  a  record  cf  type  ACCESS_CLASS 
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and  it  consisted  of  two  fields:  level  —  16  bit  integer  and 
category  —  16  bit  integer,  a  pointer  type  CPTR  was  declared 
to  be  of  type  pointer  to  ACCESS_CLASS.  Two  other  pointers 
CLASS1_PTR  and  CLASS2_PTR  were  declared  to  be  of  type  CPTR 
and  were  set  equal  to  the  base  address  of  CLASS1  and  CLASS 2 
respectively.  This  "overlay"  of  the  record  frame  over  the 
two  classification  labels  passed  as  arguments  allowed  the 
desired  component  addressibilitv.  Futhermore,  the  non-dis- 
cretionary  policy  enforced  by  SASS  can  be  changed  from  the 
current  DoD  policy  to  another  lattice  policy  by  changing 
(only)  the  NDS  Module. 

D.  DISTRI BOJED  MEMORY  MANAGER  MODOLE 

The  Distributed  Memory  Manager  Module  performs  as  an  in¬ 
terface  between  the  Segment  Manager  and  the  Memory  Manager 
Process.  As  its  name  implies,  it  is  distributed  in  the  ker¬ 
nel  domain  of  each  Supervisor  process.  The  key  role  per¬ 
formed  in  this  module  is  to  arrange  and  perform  interprocess 
communication  between  its  process  (actually  the  VP)  and  the 
memory  manager  process  (VP).  The  module  consists  of  eight 
procedures.  Six  of  the  procedures  are  called  directly  by 
Segment  Manager  procedures;  they  are  MH_CREATE_ENTR Y , 
MM_DELEI2_SNTRY,  MM_ ACTIVATE,  MM_DE ACTIVATE ,  MM_SKAP_IN,  and 
MM_sWA?_oar.  The  other  two  procedures  are  "service"  proce¬ 
dures  called  by  multiple  procedures;  they  are: 
MM_GET  DBF. VALUE  and  PERFORM_IPC.  The  logic  used  in  the 
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first  six  procedures  is  somewhat  uniform  (except  for 
MH  ACTIVATE) .  Thus,  the  general  logic  will  be  explained 
(with  MM_CREATE_ENTRY  as  an  example)  and  it  should  suffice 
as  a  description  for  all  (except  MM_ACTIVATE)  procedures. 
The  service  procedures  will  be  described  separately. 

1 •  Description  of  Procedures 

Each  procedure  is  invoiced  (and  returns)  on  a  one  to  one 
basis  with  a  corresponding  procedure  in  the  Segment  Manager. 
For  example,  CREAT E_SEGMENT  invokes  MM _CRE ATE_ENTR Y  which 
signals  the  CREATE_ENTRY  procedure  in  the  Memory  Manager 
Process  Module.  Associated  with  each  procedure  is  an  IPC 
message  "frame”  to  describe  the  unique  format  of  the  con¬ 
tents  of  the  message  to  be  signalled  to  the  memory  manager 
process.  Similarly,  there  must  be  a  message  "frame"  for  re¬ 
turn  messages  from  the  memory  manager  process;  this  frame  is 
the  same  for  all  but  the  MM_ACTIVATE  procedure.  Consider  the 
message  frame  for  MM_CREATE_ENTRY ;  it  consists  of:  (1)  a 
code  to  describe  which  function  is  to  be  performed  (e.g., 
CREATE_CODE  indicates  that  the  CREATE_ENTRY  procedure  is  the 
intended  recipient  of  the  message),  (2)  MM_Handle  (an  array 
of  three  words)  ,  (3)  Entry_No,  (4)  size,  and  (5)  Class.  The 
message  frame  has  a  filler  (in  this  case)  of  one  byte  to  en¬ 
sure  that  it  is  of  length  16  bytes.  The  purpose  of  this 
frame  is  to  provide  an  overlay  onto  the  actual  message  array 
to  be  signalled  and  to  facilitate  loading  the  arguments  into 
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the  message  array.  This  is  accomplished  by  having  a  pointer 
of  the  type  that  points  to  the  frame  but  by  converting  its 
address  so  that  ~t  actually  points  to  the  base  of  the  mes  — 
sage  array.  Consider  these  lines  of  PLZ/SYS  code: 

CE_HSGPTR  .*=  CE_PTR  COM_MSGPTR 
CE_KSGPTR-«.  CBEATE_CODE  :=  CRE  AT  E_ENTRY_C3DE 

This  code  is  putting  a  value  into  the  structure  pointed  to 
by  C3_BSGPTR  at  entry  CREATE_CODE.  The  key  point  is  that 
the  frame  of  that  structure  is,  in  fact,  CREATE_SSG  (as  de¬ 
scribed  before) ,  but  the  physical  location  pointed  to  is  the 
message  array.  This  is  assured  by  having  the  pointer 
CE_HS GPTR  (which  points  to  a  structure  of  type  C£EATE_BSG) 
set  egual  to  a  pointer  (COM_HSG?TR)  to  the  actual  message 
array  (COK_MSGDUF) .  This  is  accomplished  by  the  first  line 
of  code.  The  message  array  itself  is  never  directly  refer¬ 
enced,  but  rather  the  message  array  that  is  overlayed  by  the 
message  frame  is  filled  in  the  format  of  the  CRE ATE_MSG 
frame.  In  this  example,  the  first  two  bytes  of  the  message 
array  now  contain  the  value  cf  the  constant 
C REATE_EN?R Y_C3 DE .  The  remainder  of  the  message  array  is 
filled  in  the  same  manner  (all  procedures  use  the  same  no¬ 
tion  of  a  frame,  although  the  frames  have  different  for¬ 
mats)  .  The  PERFORM_IPC  (perform  interprocess  communication) 
procedure  is  called  by  all  procedures  at  this  point  in  their 
execution.  The  key  is  that  the  argument  passed  is  the  mes¬ 
sage  array  pointer  not  the  pointer  to  the  CSZATE_MSG  record 
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(after  all  it  is  only  an  overlay  frame  --  linguistically,  it 
is  only  a  type  and  is  never  declared  as  a  structure  requir¬ 
ing  memory  storage  allocation) .  When  PEfiFORM_IPC  returns, 
the  message  array  contains  a  return  message.  This  message 
consists  of  only  a  success  code  and  filler  space  in  all  cas¬ 
es  but  MM_ACTIV ATE.  Interpretation  of  the  return  message  is 
performed  in  the  same  manner  as  loading  the  message  array. 
The  retrieved  success  code  is  returned  to  the  calling  Seg¬ 
ment  Manager  procedure.  For  MM_ACTIVAIE,  the  return  message 
must  be  interpreted  and  values  for  success  code,  segment 
size,  and  segment  classification  retrieved  and  returned  to 
the  Segment  Manager  MAKE_KNOWN  procedure.  The  value  for  the 
MM_Handle  (called  the  G_AST_Handle  by  the  memory  manager 
process)  must  be  retrieved  and  entered  in  the  KST  record  for 
this  segment. 

2 •  Interprocess  Communication 

The  final  arrangements  and  actual  performance  of  IPC  is 
completed  by  the  internal  procedure  PERFORM_IPC.  By  locating 
the  identity  of  the  current  physical  processor  (CPU)  and  us¬ 
ing  that  identity  to  index  into  the  MM_CPU_TA BLE,  the  VP_ID 
of  the  current  memory  manager  is  resolved,  so  that  the  memo¬ 
ry  manager  process  dedicated  to  this  physical  processor  is 
signalled.  The  call  to  K_LOCK  is,  in  fact,  a  disguised  call 
to  the  SPI N_LOCK  procedure  (since  K_LOCK  calls  SPIN_LOCK) . 
K_LOCK  represents  an  ultimate  (as  yet  unimplemented)  goal  of 
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the 


a  Kernel  locking  (wait-lock)  system.  in  any  event, 

G_ AST  lock  must  be  set  prior  to  signalling  the  memory  manag¬ 
er  process.  After  SIGNAL  has  been  called,  a  call  is  made  to 
WAIT  with  the  pointer  to  the  message  array  as  the  argument. 
The  synchronization  cycle  that  results  is:  (1)  PERFORM_IPC 
calls  the  ITC  procedure  SIGNAL  with  the  memory  manager  VP_ID 
and  message  array  pointer  as  arguments;  PERFORM_IPC  then 
calls  WAIT  with  the  message  array  as  the  argument,  (2) 
SIGNAL  causes  the  message  array  to  be  copied  into  the  mes¬ 
sage  queue  (in  the  VPT)  of  the  appropriate  vp_iD,  (3)  ulti¬ 
mately,  the  signalled  VP  is  scheduled;  it  had  previously 
called  WAIT,  passing  a  pointer  to  its  own  local  message  ar¬ 
ray;  the  action  of  WAIT  is  to  copy  the  message  from  the  VPT 
to  the  signalled  process*  local  message  array;  there  it  is 
interpreted  by  the  memory  manager  process  main  procedure  and 
the  appropriate  procedure  is  called  for  action  (e.g., 
CREATE_ENT3I) ,  (4)  when  action  is  completed  the  memory  man¬ 
ager  process  fills  its  local  message  array  with  the  appro¬ 
priate  return  message  and  calls  SIGNAL  with  a  pointer  to  the 
message  and  the  original  signalling  process'  VP_ID  as  argu¬ 
ments,  (5)  SIGNAL  causes  the  memory  manager  process'  message 
to  be  copied  into  the  VPT  message  queue  for  the  appropriate 
VP_ID,  (6)  that  VP  is  eventually  scheduled  and  through  the 
action  of  WAIT  has  the  return  message  copied  from  its  mes¬ 
sage  queue  in  the  VPT  to  its  local  message  array;  WAIT  then 
returns  to  PERFORM  IPC.  The  G_ AS T  lock  is  unlocked  and 
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PERFORM_IPC  returns  to  the  appropriate  distributed  memory 
manager  procedure. 

The  last  procedure  in  the  distributed  memory  manager  is 
M M_GET_DBR_ VALUE.  This  procedure  simply  provides  the  ser¬ 
vice  of  translating  a  DBR_NO  (D8R  number)  into  its  appropri¬ 
ate  DBR  address.  It  is  called  by  the  TC_GETWQRK  procedure  to 
allow  it  to  call  the  ITC  procedure  SWAP_VDBR  (remember  that 
presently  the  Inner  Traffic  Controller  deals  with  the  DBR  as 
the  address  of  the  appropriate  MMU  record  in  the  MMU_IMAGE 
while  the  Traffic  Controller  uses  DBR  as  a  DBR  number  which 
indexes  to  the  appropriate  MMU  record) . 

E.  SUMMARY 

The  implementation  of  segment  management  functions  and  a;' 
non-discretionary  security  policy  for  the  SASS  has  been  pre¬ 
sented  in  this  chapter.  The  implementation  of  the  Segment 
Manager  Module,  Mon-Discretionary  Security  Module,  and  Dis¬ 
tributed  Memory  Manager  management  demonstration  was  de¬ 
scribed. 
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Chapter  XIX 

CONCLUSIONS  AND  FOLLOH  ON  HOBK 


the  securi- 


The  implementation  of  segment  management  for 
ty  Kernel  of  a  secure  archival  storage  system  has  been  pre¬ 
sented.  The  implementation  was  completed  on  Zilog*s  Z8002 
sixteen  bit  nonsegmented  microprocessor.  Segmentation  hard¬ 
ware  {Zilog's  Z80 1 0  Memory  Management  Unit)  was  not  availa¬ 
ble,  therefore  it  was  simulated  in  software  as  described  by 
Reitz  [12].  The  loop  free  modular  construction  used  in  the 
implementation  facilitates  ease  of  expansion  or  modifica¬ 
tion. 


A  non-discr etionary  security  policy  was  implemented  us¬ 
ing  a  partially  ordered  lattice  structure  as  a  basis.  En¬ 
forcement  was  realized  through  an  algorithm  that  compared 
two  labels  and  determined  if  their  relationship  was  equal  to 
a  desired  relationship.  Although  the  DqD  security  classifi¬ 
cation  system  was  represented,  any  non-discretionary  securi¬ 
ty  policy  that  may  be  represented  by  a  lattice  structure  may 
similarly  be  implemented.  This  implementation  has  shown  that 
by  having  the  non-discretionary  security  policy  enforced  in 
one  module,  changing  to  another  policy  requires  changing 
only  this  one  module. 
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Software  engineering  techniques  used  in  previous  work 
emphasized  the  advantages  of  working  with  code  that  is  well 
structured,  well  documented,  and  well  organized.  Despite  be¬ 
ing  written  in  assembly  language,  Reitz'  implementation  of 
multiprogramming  and  process  management  proved  to  be  consis¬ 
tent  in  style,  clarity  and  documentation.  This  enhanced  the 
construction  of  a  segment  management  demonstration  which  was 
built  onto  his  synchronization  demonstration.  Further,  re¬ 
finements  made  to  his  code  (not  necessitated  by  any  failures 
of  his  code)  were  relatively  easily  accomplished. 

while  the  segment  management  implementation  appears  to 
perform  properly,  it  has  not  been  subjected  to  a  formal  test 
plan.  Such  a  test  plan  should  be  developed  and  implemented. 

The  Memory  Manager  Process  has  been  designed  but  not  im¬ 
plemented.  Segment  management  implementation,  provision  for 
IPC  using  more  practical  size  messages,  and  the  detailed  de¬ 
sign  of  the  memory  manager  by  Moore  and  Gary  [5],  provide  a 
sound  foundation  for  memory  manager  implementation.  A  frame¬ 
work  of  the  mainline  code  needed  is  provided  in  the  Memory 
Manager  Module  of  the  demonstration  code  in  Appendix  J.  Pri¬ 
or  to  this  implementation,  fornral  testing  of  the  segment 
management  implementation  herein  and  the  monitor  implemented 
by  Reitz  [12]  should  be  completed. 
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PAST  F 

IMPLEMENTATION  OF  PROCESS  MANAGEMENT  POR  A 
SECURE  ARCHIVAL  STORAGE  SISTEM 


This  section  contains  excerpts  from  a  Naval  Postgraduate 


School  MS  Thesis  by  A.  R.  Striclcler 
these  excerpts  are: 

[19]. 

The  origins 

INTRODUCTION 

from 

Chapter  I 

IMPLEMENTATION  ISSUES 

from 

Chapter  III 

PROCESS  MANAGEMENT  IMPLEMENTATION 

from 

Chapter  IV 

CONCLUSION 

from 

Chapter  V 

Minor  changes  have  been  made  for  integration  into  this  report 


Chapter  XX 
INTBODUCT ION 

This  thesis  addresses  the  implementation  of  process  man¬ 
agement  functions  for  the  Secure  Archival  Storage  System  or 
SASS.  This  system  is  designed  to  provide  multilevel  secure 
access  to  information  stored  for  a  network  of  possibly  dis¬ 
similar  host  computer  systems  and  the  controlled  sharing  of 
data  amongst  authorized  users  of  the  SASS.  Effective  pro¬ 
cess  management  is  essential  to  insure  efficient  use  and 
control  of  the  system. 

The  major  accomplishments  of  this  thesis  effort  include 
the  provisions  for  efficient  process  creation  and  manage¬ 
ment.  These  functions  are  provided  through  the  establish¬ 
ment  of  a  system  Traffic  Controller  and  the  creation  of  a 
virtual  interrupt  structure.  An  effective  mechanism  for  in¬ 
ter-process  communication  and  synchronization  is  realized 
through  an  Event  Manager  that  makes  use  of  uniquely  identi¬ 
fied  segments  supported  by  eventcount  and  sequencer  primi¬ 
tives.  A  hardware  controlled  two  domain  operational  envi¬ 
ronment  is  created  with  the  necessary  interfacing  between 
domains  provided  by  a  software  "gate"  mechanism.  Additional 
support  is  provided  through  considerable  work  in  the  area  of 
database  initialization  and  a  technique  for  limited  dynamic 
memory  allocation. 
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This  implementation  was  completed  on  the  commercial  AMC 
Am96/4116  MonoBoard  Computer  wirh  a  standard  Multibus  inter¬ 
face. 
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Chapter  XXI 
I MPLEHENTATION  ISSUES 

Issues  bearing  on  the  implementation  or  process  manage¬ 
ment  and  refinements  made  to  existing  modules  are  presented 
in  this  chapter.  Process  management  for  the  S&SS  was  pro¬ 
vided  through  the  implementation  of  the  Traffic  Controller 
Module,  the  Event  Manager  Module,  the  Distributed  Memory 
Manager  Module,  and  a  Gate  Keeper  Stub  (system  trap) .  Addi¬ 
tionally,  since  a  demonstration/testbed  was  integral  to  the 
testing  and  verification  of  the  implementation,  it  was  ne¬ 
cessary  to  complete  other  supportive  tasks.  These  suppor¬ 
tive  tasks  included  limited  Kernel  database  initialization, 
revised  preempt  interrupt  handling  mechanisms.  Idle  process 
definition  and  structure,  and  additional  refinements  to  ex¬ 
isting  modules. 

A .  DAXABASE  INITIALIZATION 

Previous  work  on  SASS  has  relied  on  statically  built  da¬ 
tabases,  which  proved  to  be  sufficient  for  demonstration  of 
a  single  processor,  single  host  supported  system.  In  the 
current  demonstration,  multiple  hosts  are  simulated,  and  the 
Kernel  data  structures  have  been  refined  to  represent  a  mul¬ 
tiprocessor  environment.  Since  a  multiprocessor  system  was 
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several 


unavailable  at  the  time  of  this  demonstration* 

"runs"  were  made  and  traced,  using  different  logical  CPU 
numbers,  to  show  the  correctness  of  this  structure.  Due  to 
this  multiprocessor  representation  and  simulation  of  multi¬ 
ple  hosts,  the  use  of  statically  built  Kernel  databases  was 
no  longer  convenient.  Therefore,  it  became  necessary  to 
provide  initialization  routines  for  the  dynamic  creation  of 
these  Kernel  databases  required  for  this  implementation. 
While  it  was  not  the  intent  of  this  effort  to  implement  sys¬ 
tem  initialization,  care  was  taken  in  the  writing  of  these 
initializing  routines  so  that  they  might  be  utilized  in  the 
system  intiaiiz ation  implementation  with,  hopefully,  minimal 
refinement.  Database  initialization  was  restricted  to  those 
databases  existing  in  the  Inner  Traffic  Controller  and  the 
Traffic  Controller.  Limited  elements  of  the  Known  Segment 
Table  (KST)  and  Global  Active  Segment  Table  (G_AST)  were 
also  created  for  demonstration  purposes. 

1  •  In Traffic  Controller  Initialization 

A  "Bootstrap  Loader"  Module,  which  logically  exists  at  a 
higher  level  of  abstraction  within  the  Kernel,  was  created 
to  initialize  the  databases  of  the  Inner  Traffic  Controller. 
This  initialization  includes  the  creation  of:  1)  the  Pro¬ 
cessor  Data  Segment  (PRDS) ,  2)  an  MMU  Map,  3)  Kernel  domain 
stack  segments  for  Kernel  processes,  4)  allocation  and  up¬ 
dating  of  MMU  entries  for  Kernel  processes,  and  5)  Virtual 
Processor  Table  (VPT)  entries. 
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The  PRDS  was  loaded  with  constant  values  that  specify 
the  physical  CPU  ID,  logical  CPU  ID,  and  number  of  VP's  al¬ 
located  to  the  CPU.  A  design  decision  was  made  to  allocate 
logical  CPU  ID's  in  increments  of  two  (beginning  with  zero) 
so  that  they  could  be  used  to  directly  access  lists  indexed 
by  CPU  number.  The  MMU  map,  constructed  as  a  "byte"  map, 
was  created  to  specify  allocated  and  free  MMU  Image  entries. 

A  separate  procedure,  CREATE_STACK,  was  created  to  es¬ 
tablish  the  initial  Kernel  domain  stack  conditions  for  Ker¬ 
nel  processes.  A  discussion  and  diagram  of  these  initial 
stack  conditions  is  presented  in  the  next  section. 
ALLOCATE_MMU  checks  the  MMU  hap  and  allocates  the  next 
availabe  MMU  entry  to  the  process  being  created.  The  PRDS 
is  inserted  in  the  allocated  MMU  entry  and  the  DBR  number  is 
returned  to  the  calling  procedure.  The  DBR  number  (handle) 
is  merely  the  offset  of  the  DBR  in  the  MMU  Image.  Since  the 
ITC  deals  with  an  address  rather  than  a  handle,  a  procedure, 
GET_DBR_ADDR ,  was  created  to  convert  this  offset  into  a  phy¬ 
sical  address.  UPDATE_MMU_IMAGE  is  the  procedure  which 
creates  or  modifies  MMU  Image  entries.  UPDATE_MMU_IMAGE  ac¬ 
cepts  as  arguments  the  DBR  number,  segment  number,  segment 
attributes,  and  segment  limits.  To  facilitate  process 
switching  and  control,  various  process  segments  must  possess 
the  same  segment  number  system  wide.  This  is  accomplished 
during  initialization  through  the  use  of  the 
UPDATE_MMU_IMAGE  procedure.  In  the  ITC,  these  segments  in- 
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elude  the  PHDS  (segment  number  zero)  and  the  Kernel  stack 
segment  (segment  number  one). 

The  final  task  required  in  ITC  intializat ion  is  the 
creation  of  the  V?T.  The  VPT  header  is  initialized  wit)  the 
"running"  and  "ready"  lists  pointers  set  to  a  'nil*  state, 
and  the  "free"  list  pointer  set  to  the  first  entry  in  the 
message  table.  Virtual  Processor  entries  are  inserted  in 
the  main  body  of  the  VPT  by  the  UPDATE_YP_I ABLE  procedure. 
Entries  are  first  made  for  the  VP's  permanently  bound  to  the 
Memory  Manager  and  Idle  processes.  The  VP  bound  to  the  MM 
process  is  given  a  priority  of  2  (highest) ,  and  the  VP  bound 
to  the  Idle  process  is  given  a  priority  of  0  (lowest)  .  The 
External  VP  ID  for  both  of  these  VP's  is  set  to  "nil"  as 
they  are  not  visible  to  the  Traffic  Controller.  The  remain¬ 
ing  VP's  allocated  to  the  CPU  (viz.,  TC  visible  VP's)  are 
then  entered  in  the  VPT  with  a  priority  of  1  (intermediate)  , 
and  their  "idle"  and  "preempt"  flags  are  set.  The  preempt 
flag  is  set  for  these  TC  visible  VP's  to  insure  proper  sche¬ 
duling  by  the  Traffic  Controller,  The  DBK  for  these  remain¬ 
ing  VP's  is  initialized  with  the  Idle  process  DBH.  A  dis¬ 
cussion  of  "idle"  processes  and  VP's  will  be  provided  later 
in  this  chapter.  The  External  7P  ID  for  each  TC  visible  VP 
is  merely  the  offset  of  the  next  available  entry  in  the 
EXTERNAL  VP  LIST.  This  External  VP  ID  is  entered  in  the 
VPT,  and  the  corresponding  VP  ID  (viz.,  VPT  Entry  %)  is  en¬ 
tered  in  the  EXTERNAL  VP  LIST. 
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Once  these  VPT  entries  have  been  made,  it  is  necessary 
to  set  the  state  of  each  VP  to  "ready"  and  thread  them  (by 
priority)  into  the  appropriate  ready  list.  A  VPT  threading 
mechanism  was  provided  by  Reitz  M2]  in  procedure 
MAKE_READY.  However,  it  was  desired  to  have  a  more  general 
threading  mechanism  that  could  be  used  for  other  lists. 
Procedure  LI ST_INSERT  was  created  to  provide  this  general 
threading  mechanism.  LIST_I NSERT  is  logically  a  "library" 
function  that  exists  at  the  lowest  level  of  abstraction  in 
the  Kernel.  This  function  threads  an  object  into  a  list 
(specified  by  the  caller)  in  order  of  priority,  and  then 
sets  its  state  as  specified  by  the  calling  parameters. 

Once  the  "Bootstrap  Loader"  has  completed  ITC  initiali¬ 
zation,  it  passes  control  to  the  ITC  GETMORK  procedure  to 
begin  VP  scheduling. 

2.  Traffic  Controller  Initialization 

The  initialization  routines  for  the  TC  include  TC_INIT, 
CREATE_PROCSSS,  and  CREATE_KST.  These  routines  are  called 
from  the  Memory  Manager  process.  The  MM  process  was  chosen 
to  initiate  these  routines  as  it  is  bound  to  the  highest 
priority  VP  and  will  begin  running  immediately  after  the  In¬ 
ner  Traffic  Controller  is  initialized.  Procedure 
MM_ALLOCATE  was  written  to  allocate  memory  space  for  data 
structures  during  initialization  (viz..  Kernel  stacks,  user 
stacks,  and  KST's) .  Memory  space  is  allocated  in  blocks  of 
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100  (hex)  bytes.  f1M_ALLOCATE  is  merely  a  stub  of  the  memory 
allocating  procedure  designed  by  Moore  and  Gary  [5], 

It  was  necessary  to  pass  long  lists  of  arguments  to  the 
TC  for  initialization  purposes.  To  aid  in  this  passing  of 
parameters,  a  data  structure  template  was  used.  This  temp— 
late  was  created  by  declaring  the  parameters  as  a  data 
structure  in  both  the  sending  and  receiving  procedures,  and 
then  imaging  this  structure  at  absolute  address  zero.  The 
process'  stack  pointer  was  then  decremented  by  the  size  of 
the  parameter  data  structure,  and  the  parameters  were  loaded 
into  this  data  structure  indexed  by  the  stack  pointer.  This 
template  made  it  very  easy  to  send  and  receive  long  argument 
lists  using  the  process'  stack  segment. 

TC_INIT  initializes  the  APT  header  and  virtual  interrupt 
vector  (discussed  later).  Each  element  of  the  running  list 
is  marked  "idle",  the  ready  and  blocked  lists  are  set  to 
"nil",  and  the  number  of  VP's  and  first  VP  for  each  CPU  are 
entered  in  the  VP  table.  The  address  of  the  virtual  preempt 
handler  is  then  passed  to  the  ITC  procedure  C3E ATE_IST_VEC 
for  insertion  in  the  virtual  interrupt  vector. 

CREATE_PROCESS  intializes  user  processes  and  creates  en¬ 
tries  in  the  APT.  ALLOCATE_MMU  is  called  to  acquire  a  DBR 
number,  and  an  APT  entry  is  created  with  the  process  de¬ 
scriptors  (viz. ,  parameters) .  The  process  is  then  declared 
"ready"  and  threaded  into  the  approciate  ready  list  by 
calling  the  threading  function,  LIST_3INSEET.  A  user  stack 
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is  allocated  and  UP D AT E_M M(J_ IM AG E  is  called  to  include  the 
user  stack  in  the  HMU  as  segment  number  three.  The  user 
stack  contains  no  information  or  user  process  initialization 
parameters  (viz.,  execution  point  and  address  space)  as  all 
processes  are  initialized  and  begin  execution  from  the  Ker¬ 
nel  domain.  Next,  a  Kernel  domain  stack  is  allocated  and 
included  in  the  MMU  Image.  A  design  decision  was  made  to 
initialize  the  Kernel  stacks  for  user  processes  with  the 
same  structure  as  the  Kernel  process'  stacks.  The  rationale 
for  this  decision  is  presented  in  the  next  section.  As  a 
result  of  this  decision,  it  became  possible  to  use  the 
CREATE_STACK  procedure  in  building  Kernel  domain  stacks  for 
both  Kernel  and  user  prosesses.  CBEATE_STACK  was  therefore 
used  as  a  library  function  and  placed  in  the  library  module 
with  LIST-INSERT. 

Finally,  a  Known  Segment  Table  (KST)  stub  is  created  to 
provide  a  means  of  demonstrating  the  mechanism  provided  by 
the  eventcounts  and  sequencers  for  interprocess  communica¬ 
tion  (IPC)  and  mutual  exclusion.  Space  for  the  process'  KST 
is  created  by  calling  MM_ALLOCATE.  The  KST  is  then  included 
in  the  process'  address  space,  as  segment  number  two,  by 
UPDATE_MSU_IilAGE.  Initial  entries  are  made  in  the  Known 
Segment  Table  by  procedure  CREATE_KST.  CREATE_KST  makes  an 
entry  in  the  KST  for  the  "root"  and  marks  the  remaining  KST 
entries  as  "available."  The  Unique_ID  portion  of  the  root's 
handle  {viz.,  upper  two  words)  is  initialized  as  -1  (for 
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conve mence)  and  the  G_AST  entry  number  portion  of  the  han¬ 
dle  (viz.,  lowest  word)  is  initialized  with  zero. 

3.  Additional  Initialization  Requirements 

As  already  mentioned,  the  Memory  Manager  Process  prepares 
the  arguments  utilized  by  TC_INIT,  CREATE_PROCESS ,  and 
CREATE_KST  for  TC  initialization  and  user  process  creation. 
Additionally,  the  MM  process  creates  a  Global  Active  Segment 
Table  (G_AST)  stub  utilized  for  demonstration  of  event  data 
management.  The  G_AST  stub  is  declared  in  a  separate  module 
(viz.,  the  DEMO_DATA B ASE  Module)  with  the  format  prescribed 
by  Moore  and  Gary  [5].  However,  the  only  fields  initialized 
and  utilized  by  this  implementation  are  UN1Q0E_ID, 
SEQUENCER,  INSTANCE  1,  and  INSTANCE  2.  The  eventcounts  and 
sequencer  fields  are  initialized  as  zero  whenever  an  entry 
is  created  in  the  G_AST.  The  UNIQUE_ID  is  created  just  to 
support  this  demonstration  and  does  not  reflect  the  seg¬ 
ment's  unique  identifier  as  specified  by  Moore  and  Gary  [5]. 
In  this  demonstration,  UNIQUE_ID  is  built  with  the  parame¬ 
ters  passed  to  MM_ACTIV ATE .  The  first  word  in  U!IIQUE_ID  is 
the  G_AST  entry  number  of  the  segment's  parent,  and  the  sec¬ 
ond  word  is  the  segment's  entry  number  into  the  alias  table. 
The  UNIQUE_ID  together  with  the  offset  of  tne  segment's  en¬ 
try  in  the  G_AST  comprise  the  segment  HANDLE  maintained  in 
the  KST.  The  first  entry  in  the  G„AST  is  reserved  for  the 
root,  and  is  initialized  with  an  Unique_ID  of  minus  one 
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(-1).  It  should  be  noted  that  any  call  to  MM_ACTIVATE  for  a 
segment  already  possessing  an  entry  in  the  G_AST  will  not 
effect  any  changes  to  that  entry.  This  is  to  insure  that  a 
single  G_AST  entry  exists  for  every  segment  as  specified  by 
Moore  and  Gary  [5]. 

B.  PREEMPT  INTERRUPTS 

Various  refinements  were  made  in  the  handling  of  both 
physical  (hardware)  and  virtual  (software)  preempt  inter¬ 
rupts.  A  hardware  preempt  is  a  non-vectored  interrupt  that 
invokes  the  virtual  processor  scheduling  mechanism  (viz., 
ITC  GSTWORK) .  a  virtual  preempt  is  a  software  vectored  in¬ 
terrupt  that  invokes  the  user  process  scheduling  mechanism 
(viz.,  TC_GETWORK)  .  This  implementation  provides  the  notion 
of  a  virtual  interrupt  that  closely  mirrors  the  behavior  of 
a  hardware  interrupt.  In  particular,  there  are  similar  con¬ 
structs  for  initialization  of  a  handler,  invokation  of  a 
handler,  masking  of  interrupts,  and  return  from  a  handler. 
As  with  most  hardware  interrupts,  a  victual  interrupt  can 
occur  only  at  the  completion  of  execution  for  an  "instruc¬ 
tion,"  where  each  kernel  entry  and  exit  for  a  process  delim¬ 
it  a  single  "virtual  instruction." 
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1 .  Physical  Preempt  Handler 

The  physical  preempt  handler  resides  in  the  virtual  pro¬ 
cessor  manager  (viz.  r  Inner  Traffic  Controller) .  The  func¬ 
tions  it  perform  are:  1)  save  the  execution  point,  2)  in¬ 
voke  ITC  GETWORK,  3)  check  for  virtual  preempt  interrupts, 
4)  restore  the  execution  point,  and  5j  return  control  via 
the  IRET  instruction.  Reitz  (12]  included  the  hardware 
preempt  handler  in  ITC  GETWORK  by  establishing  two  entry 
points  and  two  exit  points,  one  for  a  regular  call  to 
GETWORK  and  another  for  the  preempt  interrupt.  He  had  a  se¬ 
parate  procedure,  TEST_PREEMPT,  that  was  used  to  check  for 
the  occurrence  of  virtual  preempt  interrupts.  This  structure 
works  nicely,  but  it  requires  some  means  of  determining  how 
GETWORK  was  invoked  so  that  the  proper  exiting  mechanism  is 
used.  This  was  resolved  by  incorporating  a  preempt  inter¬ 
rupt  flag  in  the  status  register  block  of  every  process' 
Kernel  domain  stack  segment.  A  design  decision  was  made  to 
restructure  the  hardware  preempt  handler  into  a  single  and 
separate  procedure,  PHYS_PREEMPT_HAHDLER.  This  allowed  ITC 
GETWORK  to  have  a  single  entry  and  exit  point,  and  it  did 
away  with  the  necessity  of  maintaining  a  preempt  interrupt 
flag  in  the  process  stacks.  PH YS_PRSEHPT_H ANDLER  was  con¬ 
structed  from  the  preempt  handling  code  in  GETWORK  and 
procedure  TEST_PHSEMPT.  TEST_PREEMPT  was  deleted  from  the 
ITC  as  its  functions  were  performed  by  PHYS_PREEMPT-HANDLES. 
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A  further  refinement  was  made  to  the  hardware  preempt 
handler  dealing  with  the  method  by  which  the  virtual  preempt 
handler  was  invoiced.  Reitz  [12]  invoiced  the  virtual  preempt 
handler  from  TEST_PREEMPT  by  means  of  the  "call"  instruc¬ 
tion.  Since  the  virtual  preempt  handler  logically  exists  at 
a  higher  level  of  abstraction  than  the  ITC,  this  invocation 
violated  our  notion  of  only  allowing  "calls"  to  lower  or 
equal  abstraction  levels.  However,  this  deviation  was  ne¬ 
cessitated  by  the  absence  of  a  virtual  interrupt  structure. 
This  problem  was  alleviated  by  creating  a  virtual  interrupt 
vector  in  the  ITC  that  is  used  in  the  same  way  as  the  hard¬ 
ware  interrupt  vector.  The  virtual  preempt  was  given  a  vir¬ 
tual  interrupt  number  (zero).  The  virtual  interrupt  handler 
is  then  invoked  by  means  of  a  "jump"  through  the  virtual  in¬ 
terrupt  vector  for  virtual  interrupt  number  0.  This  invoca¬ 
tion  occurs  in  the  same  manner  that  the  handlers  for  hard¬ 
ware  interrupts  are  invoked.  The  virtual  interrupt  vector 
is  created  by  procedure  CHEAT E_INT_VEC.  CRE ATE_INT_VEC  ac¬ 
cepts  as  arguments  a  virtual  interrupt  number  and  the  ad¬ 
dress  of  the  interrupt  handler.  The  creation  of  the  virtual 
preempt  entry  in  the  virtual  interrupt  vector  is  accom¬ 
plished  at  the  time  of  the  Traffic  Controller  initialization 
by  TC_INIT. 
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2.  Virtual  Preempt  Handler 

The  virtual  preempt  handler  (VIRT_PBEEMPT_HANDLER)  re¬ 
sides  in  the  user  process  manager  (viz.,  the  Traffic  Cont¬ 
roller)  .  The  functions  performed  by  VIRT_PREEMPT_HANDLER 
are:  1)  determine  the  VP  ID  of  the  virtual  processor  being 
preempted,  2)  invoke  the  process  scheduling  mechanism  (viz., 
TC_GETWORK)  ,  and  3)  return  control  via  a  virtual  interrupt 
return.  The  correct  VP  ID  is  obtained  by  calling  R(JNNING_VP 
in  the  ITC.  The  Active  Process  Table  is  then  locked,  and 
the  state  of  the  process  running  on  that  VP  is  changed  to 
'’ready.1'  At  this  time,  process  scheduling  is  effected  by 
calling  TC_GETVORK.  Once  process  scheduling  is  completed, 
the  APT  is  unlocked  and  control  is  returned  via  a  virtual 
interrupt  return.  This  virtual  interrupt  return  is  merely  a 
jump  to  the  PREEMPT_RET  label  in  the  hardware  preempt  han¬ 
dler  (This  jump  emulates  the  action  of  the  IRET  instruction 
for  a  hardware  interrupt  return).  This  label  is  the  point 
at  which  the  virtual  preempt  interrupts  are  unmasked. 

All  Kernel  processes  are  initialized  to  appear  as  thougn 
they  are  returning  from  a  hardware  preempt  interrupt.  All 
user  processes  initially  appear  to  be  returning  from  a  vir¬ 
tual  preempt  interrupt.  Therefore,  the  initial  conditions 
of  a  process'  Kernel  domain  stack  is  largely  influenced  by 
the  stack  manipulation  of  the  preempt  handlers.  Figure  44 
illustrates  the  initial  Kernel  domain  stack  structure  for 
all  system  processes. 
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value  is 


The  initial  Kernel  Flag  Control  Word  (FCW) 

"5 000”,  indicating  non-segmented  code,  system  mode  of  opera¬ 
tion,  non-vectored  interrupts  masked,  and  vectored  inter¬ 
rupts  enabled.  The  Current  Stack  Pointer  value  is  set  to 
the  first  entry  in  the  stack  (viz.,  SP) .  The  IE ET  Frame  is 
the  portion  of  the  Kernel  stack  affected  by  the  IRET  in¬ 
struction.  The  first  element.  Interrupt  ID  (set  to  "FFFF”) 
is  merely  popped  off  of  the  stack  and  discarded.  The  next 
element.  Initial  FCW,  is  popped  and  placed  in  the  system 
Flag  Control  Word.  Initial  FCW  is  set  to  ”5000”  for  Kernel 
processes  and  ”1800”  (indicating  normal  mode  with  all  inter¬ 
rupts  enabled)  for  user  processes.  The  final  element  of  the 
IRET  frame.  Initial  IC  is  popped  off  of  the  stack  and 
placed  in  the  program  counter  (PC)  register.  This  value  is 
initialized  as  the  entry  address  of  the  process  in  question. 

The  "register”  entries  on  the  stack  represent  the  ini¬ 
tial  register  contents  for  the  process  at  the  beginning  of 
its  execution.  Since  the  Kernel  processes  (viz.,  MM  and 
Idle)  do  not  require  any  specific  initial  register  states, 
their  entries  reflect  the  register  contents  at  the  time  of 
stack  creation.  Initial  register  conditions  are  used  to 
provide  initial  "parameters"  required  by  the  user  processes. 
This  will  depend  largely  upon  the  parameter  passing  conven¬ 
tions  of  the  implementation  language.  The  means  for  regis¬ 
ter  initialization  was  provided  through  CREATE_PEOCESS ;  how¬ 
ever,  the  only  initial  register  condition  used  for  the  user 
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processes  in  this  demonstration  was  register  #13.  Register 
#13  was  used  to  pass  the  user  ID/Host  number  of  the  process 
created.  This  value  is  utilized  by  the  user  process  in  ac¬ 
tivating  the  segment  used  for  inter-process  communication 
between  a  Host’s  Pile  manager  and  I/O  processes.  Another 
logical  parameter  passed  to  the  user  processes  is  the  root 
segment  number.  This  did  not  require  a  register  for  passing 
in  the  demonstration  as  it  is  known  to  be  the  first  entry  in 
the  KST  for  all  processes.  The  N_S_P  entry  on  the  stack 
represents  the  initial  value  of  the  normal  stack  pointer. 
For  user  processes,  this  value  is  obtained  when  the  Supervi¬ 
sor  domain  stack  for  that  process  is  created.  For  Kernel 
processes,  this  value  is  set  to  "FFFF"  since  they  execute 
solely  in  the  Kernel  domain  and  have  no  Superivsor  domain 
stack.  The  Preempt  Return  Point  specifies  the  address  where 
control  will  be  passed  once  the  process*  VP  is  scheduled  and 
the  "return"  from  ITC  GETWORK  is  executed.  For  Kernel  pro¬ 
cesses,  this  is  the  point  within  the  hardware  preempt  han¬ 
dler  where  the  virtual  processor  table  is  unlocked.  For 
user  processes,  this  is  the  point  within  the  virtual  preempt 
handler  where  the  Active  Process  Table  is  unlocked. 

It  is  important  to  note  that  if  the  APT  was  not  unlocked 
when  a  user  process  began  its  initial  execution,  the  system 
would  become  deadlocked  and  no  further  process  scheduling 
could  occur.  It  should  be  further  noted  that  the  initial 
stack  conditions  for  user  processes  do  not  reflect  a  valid 
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history  of  execution.  The  ’•normal”  history  of  a  user  pro¬ 
cess  returning  from  ITC  GETWORK  after  a  virtual  preempt  in¬ 
terrupt  would  reflect  the  passing  of  control  through 
SWAP_VDBR  and  TC_GETWORK  to  the  point  in  the  virtual  preempt 
handler  where  the  APT  is  unlocked.  Another  "possible"  his¬ 
tory  could  reflect  the  occurrence  of  a  hardware  preempt  in¬ 
terrupt  at  the  point  in  the  virtual  preempt  handler  where 
the  APT  is  unlocked.  Such  a  history  would  be  depicted  by 
replacing  the  current  top  of  the  stack  with  the  return  point 
into  the  hardware  preempt  handler  (viz.,  at  the  point  of 
virtual  preempt  interrupt  unmasking)  and  an  additional  hard¬ 
ware  preempt  interrupt  frame  whose  IC  value  in  the  IRET 
frame  is  the  point  in  the  virtual  preempt  handler  where  the 
APT  is  unlocked.  The  current  initial  stack  condition  for 
user  processes  was  chosen  for  its  ease  of  understanding  and 
its  clear  depiction  of  the  fact  that  the  structure  of  a  Ker¬ 
nel  domain  stack  is  the  same  for  both  Kernel  and  user  pro¬ 
cesses. 

C.  IDLE  E BO CESSES 

In  the  SASS  design,  there  logically  exists  a  Kernel  do¬ 
main  "Idle"  process  for  every  physical  processor  in  the  sys¬ 
tem  and  a  Supervisor  domain  "Idle"  process  for  every  "TC  vi¬ 
sible"  virtual  processor  in  the  system.  These  processes  are 
necessary  to  insure  that  both  the  VP  scheduler  (viz. ,  ITC 
GETWORK)  and  the  process  scheduler  (TC_GETWORK)  will  always 
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have  some  object  to  schedule,  hence  precluding  any  CPU  or  VP 
from  ever  having  an  undefined  execution  point.  Since  the 
Kernel  domain  Idle  process  performs  no  useful  work,  it  could 
be  included  within  the  ITC  by  means  of  an  infinite  looping 
mechanism.  The  Kernel  Idle  process  was  maintained  separate¬ 
ly,  however,  as  it  is  hoped  that  future  work  on  SASS  will 
provide  this  Idle  process  with  some  constructive  purpose 
(e.g.,  performing  maintenance  diagnostics). 

The  Supervisor  domain  Idle  processes  (hereafter  referred 
to  as  TC  Idle  processes)  are  scheduled  (bound)  on  VP's  when 
there  are  no  user  processes  awaiting  scheduling.  Since  a  TC 
Idle  process  performs  no  user  constructive  work,  we  do  not 
want  any  VP  executing  a  TC  Idle  process  to  be  bound  to  a 
physical  processor.  In  other  words,  a  VP  bound  to  a  TC  Idle 
process  assumes  the  lowest  system  priority  (represented  by 
the  "idle  flag").  Therefore,  any  such  VP  will  have  its  idle 
flag  set  and  will  not  be  scheduled  unless  it  receives  a  vir¬ 
tual  preempt  interrupt.  Such  an  interrupt  will  allow  the  VP 
to  be  rescheduled  by  the  Traffic  Controller.  It  should  be 
obvious,  at  this  point,  that  a  TC  Idle  process  will  never 
actually  begin  execution  on  a  real  processor.  This  know¬ 
ledge  allowed  a  design  decision  to  be  made  to  only  simulate 
the  existence  of  TC  Idle  processes.  At  the  TC  level,  this 
was  accomplished  by  a  constant  value,  IDLE_PBOC,  that  was 
used  as  a  process  ID  in  the  APT  running  list,  thus  preclud¬ 
ing  the  necessity  of  any  "Idle"  entries  in  the  APT.  At  the 
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ITC  level,  any  VP  marked  "Idle"  (viz.,  the  idle  flag  set) 
was  given  the  DBR  number  (viz.,  address  space)  of  the  Kernel 
Idle  process  solely  to  provide  the  use  of  a  Kernel  domain 
stack  for  rescheduling  of  the  VP. 

D.  additional  kernel  refinements 

In  addition  to  those  already  discussed,  several  other 
refinements  to  existing  Kernel  modules  were  effected  in  this 
implementation.  One  of  these  refinements  deals  with  the  way 
virtual  processors  are  identified  by  the  Traffic  Controller. 
In  the  current  implementation,  all  TC  visible  virtual  pro¬ 
cessors  are  given  an  External  vp  ID  which  corresponds  to  its 
entry  number  in  an  External  VP  List.  This  required  a  modi¬ 
fication  to  the  ITC  procedure  EUNNING_VP.  The  benefits  der¬ 
ived  from  this  refinement  included  the  ability  to  directly 
access  the  External  VP  ID  in  the  Virtual  Processor  Table 
vice  the  requirement  of  a  run  time  division  to  compute  its 
value  and  the  ability  to  use  the  External  VP  ID  as  an  index 
into  rhe  TC  running  list. 

Refinements  were  also  made  to  the  existing  Memory  Manag¬ 
er,  File  Manager  and  10  process  stubs  used  for  demonstration 
purposes.  These  refinements  were  largely  associated  with 
the  eventcount  and  sequencer  mechanisms  utilized  in  this  im¬ 
plementation.  The  current  status  of  these  processes  is  pro¬ 
vided  in  this  report. 
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The  remaining  refinements  deal  largely  with  the  MMU  Im- 
age.  In  Moore  and  Gary's  (5]  design,  the  MMU  Image  was  man¬ 
aged  by  the  Memory  Manager  process.  This  was  largely  be¬ 
cause  the  MMD  Image  is  a  processor  local  database  and  would 
seem  well  suited  for  management  by  the  non-distributed  Ker¬ 
nel.  In  fact,  the  MMU  Image  is  utilized  mainly  by  the  ITC 
for  the  multiplexing  of  process  address  spaces.  Therefore, 
in  the  current  design,  the  MMU  Images  are  maintained  by  the 
Inner  Traffic  Controller.  However,  the  MMU  header  proposed 
by  Moore  and  Gary  (viz.,  the  BLOCKS_USED  and 
M AXIMUM_A V  AILABLE_3L0CKS  fields)  was  retained  in  the  Memory 
Manager  as  it  is  used  strictly  in  the  management  of  a  pro¬ 
cess'  virtual  core  and  is  not  associated  with  the  hardware 
MMU. 

In  Wells'  design  [20],  the  Traffic  Controller  used  the 
linear  ordering  of  the  DBS  entries  in  the  MMU  Image  as  the 
DBR  handle  (viz.,  1,2,3...).  This  required  a  run  time  divi¬ 
sion  operation  to  compute  the  DBS  numoer,  and  a  run  time 
multiplication  operation,  by  MM_GET_DBR_VALUE ,  to  recompute 
the  DBR  address  for  use  by  the  ITC.  In  the  current  design, 
the  offset  of  the  DBR  entry  in  the  MMU  Image  (obtained  at 
the  time  of  KMU  allocation)  is  used  as  the  DBS  handle  in  the 
Traffic  Controller.  Furthermore,  SWAP_VDBR  was  refined  tc 
accept  a  DBR  handle  rather  than  a  DBS  address  to  preclude 
the  necessity  of  the  Traffic  Controller  having  to  deal  witl 
MMU  addresses.  DBR  addresses  are  computed  only  within  the 
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ITC  (viz.,  by  procedure  GET_DBfi_ADDR)  by  adding  the  value  of 
the  DBR  handle  to  the  base  address  of  the  MMU  Image.  Since 
DBS  addresses  are  now  used  solely  within  the  ITC,  procedure 
M M_GET_DB8_  VALU E  was  no  longer  needed  and  was  deleted  from 
the  Memory  Manager. 

E.  SUMMARY 

The  primary  issues  addressed  in  this  thesis  effort  have 
been  presented  in  this  chapter.  Aside  from  the  process  man¬ 
agement  functions,  this  description  included  a  mechanism  for 
limited  Kernel  database  initialization,  a  revised  preempt 
interrupt  handling  mechanism,  the  creation  of  a  virtual  in¬ 
terrupt  structure,  a  definition  of  "idle"  processes  and 
their  structure,  and  a  discussion  of  the  minor  refinements 
effected  in  existing  SASS  modules.  A  detailed  description 
of  the  implementation  of  process  management  functions  for 
the  SASS  is  presented  in  the  next  chapter. 
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Chapter  XXII 

PROCESS  MANAGEMENT  IMPLEMENTATION 
The  implementation  of  process  management  functions  and  a 
gate  keeper  stub  (system  trap)  is  presented  in  this  chapter. 
The  implementation  is  discussed  in  terms  of  the  Event  Manag¬ 
er,  Traffic  Controller,  Distributed  Memory  Manager,  User 
Gate,  and  Kernel  Gate  Keeper  modules.  A  block  diagram  dep¬ 
icting  the  structure  and  interrelationships  of  these  modules 
is  presented  in  Figure  45.  Support  in  developing  the  Z8000 
machine  code  for  this  implementation  was  provided  by  a  Zilog 
MCZ  Developmental  System  operating  under  the  RIO  operating 
system.  The  Developmental  System  provided  disk  file  manage¬ 
ment  for  a  dual  drive,  hard  sectored  floppy  disk,  a  line 
oriented  text  editor,  a  PLZ/ASM  assembler,  a  linker  and  a 
loader  that  created  an  executable  image  of  each  Z8000  load 
module.  An  upload/download  capability  with  the  Am96/4116 
MonoBoard  computer  was  also  provided.  This  capability, 
along  with  the  general  interfacing  of  the  Am96/4116  into  the 
SASS  system,  was  accomplished  in  a  concurrent  thesis  endea¬ 
vor  by  Gary  Baker.  Baker's  work  relating  to  hardware  ini¬ 
tialization  in  SASS,  will  be  published  upon  completion  of 
his  thesis  work  in  June  1981. 
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Figure  45:  Implementation  Module  Structure 


A.  EVENT  MANAGER  MODULE 

The  eventcount  and  sequencer  primitives  [ 11 ],  which  are 
system-wide  objects,  collectively  comprise  the  event  data  of 
SASS.  As  mentioned  earlier,  this  event  data  is  tied  direct¬ 
ly  to  system  segments  and  is  stored  in  the  Global  Active 
Segment  Table.  There  are  two  eventcounts  and  one  sequencer 
for  every  segment  in  the  system.  These  objects  are  identi¬ 
fied  to  the  Kernel  in  user  calls  by  specif ication  of  a  seg¬ 
ment  number.  Once  this  segment  number  is  identified  by  the 
Kernel,  the  segment's  handle  can  be  obtained  from  the  pro¬ 
cess'  Known  Segment  Table.  The  segment  handle  identifies 
the  particular  entry  in  the  G_AST  containing  the  event  data 
desired. 

The  Event  Manager  module  manages  the  event  data  within 
the  system  and  provides  the  mechanism  for  interprocess  com¬ 
munication  between  user  processes.  The  Event  Manager  con¬ 
sists  of  sir  procedures.  Four  of  these  (Advance,  Await, 
Read,  and  Ticket)  represent  the  four  user  extended  instruc¬ 
tions  provided  by  the  Event  Manager.  The  remaining  two 
procedures  provide  internal  computational  support  to  include 
necessary  security  checking.  The  Event  Manager  is  invoked 
solely  by  user  processes,  via  the  Gate  Keeper,  through  uti¬ 
lization  of  the  extended  instruction  set  provided.  For  ev¬ 
ery  Event  Manager  extended  instruction  invoked  by  a  user 
process,  the  non-discretionary  security  is  verified  by  corn- 
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the  security  accsss  classification  of  the  process  in¬ 
voking  the  instruction  with  the  classification  of  the  object 
(segment)  being  accessed.  Access  to  the  user  process'  Known 
Segment  Table  is  reguired  by  the  module  in  order  to  ascer¬ 
tain  the  segment  handle  and  security  class  for  a  given  seg¬ 
ment  number.  The  PLZ/ASM  assembly  language  listing  for  the 
Event  Manager  module  is  provided  in  Appendix  A.  A  more  de¬ 
tailed  discussion  of  the  procedures  comprising  the  Event 
Manager  follows. 

1 •  Support  Procedures 

The  procedures  GET_HAN DLE  and  CQNVERT_AND_VERIFY  provide 
internal  support  for  the  Event  Manager  and  are  not  visible 
to  the  user  processes.  Procedure  CONVERT_AND_YERIFY  is  in¬ 
voked  by  the  four  procedures  representing  the  instruction 
set  of  the  Event  Manager.  The  input  parameters  to 
CONVERT_LhT _VERIFY  are  a  segment  number  and  a  reguested  mode 
of  access  (viz.,  read  or  write).  CCNVERT,>AND_VERIFY  returns 
a  pointer  to  the  segment's  handle  and  a  success  code. 
Procedure  GET_HA  NDLE  is  invoked  solely  by 
CONVERT _AND_VEBIFY.  The  input  parameter  to  GE  T_HA  NDLE  is 
the  segment  number  received  as  input  by  CONY FRT_AND_VERIPY . 
GET_HANDLE  returns  a  pointer  to  the  segment's  handle,  a 
pointer  to  the  segment's  security  classification,  and  a  suc¬ 
cess  code.  A  discussion  of  the  functions  provided  by  these 
support  procedures  follows. 
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Procedure  GET_HA NDLE  translates  the  segment  number,  re¬ 
ceived  as  input,  into  a  KST  index  number  and  verifies  that 
the  resulting  index  number  is  valid.  Next  the  base  address 
of  the  process'  KST  is  obtained  from  procedure 
ITC_GET_5E3_PTR .  The  KST  index  number  is  then  converted 
into  a  KST  offset  value  and  added  to  the  base  address  to  ob¬ 
tain  the  appropriate  KST  entry  pointer  for  the  segment  in 
question.  A  verification  is  then  made  to  insure  that  the 
referenced  segment  is  "known”  to  the  process.  If  the  seg¬ 
ment  is  not  known,  an  error  message  is  returned  to 
CONVERT_AND_VER IFY .  Otherwise,  a  pointer  to  the  segment's 
handle  is  obtained  to  identify  the  segment  to  the  memory 
manager.  A  pointer  to  the  segment's  security  class  entry  in 
the  KST  is  also  returned  for  use  in  appropriate  security 
checxs. 

Procedure  CONVE  RT_AND_VERIFY  provides  the  necessary 
non-discretionary  security  verification  for  the  extended  in¬ 
struction  set  of  the  Event  Manager.  Procedure  GEI_HANDLE 
is  invoked  for  segment  number  verification  and  to  obtain 
pointers  to  the  segment's  handle  and  security  class.  If 
GET_HANDLE  returns  with  a  successful  verification,  the  pro¬ 
cess'  security  class  is  compared  to  the  segment's  security 
class  to  verify  the  mode  of  access  requested.  A  request  for 
"write"  access  causes  invocation  of  the  CLASS_EQ  function  in 
the  Non-Discretionar y  Security  Module  to  insure  that  the  se¬ 
curity  classification  of  the  process  is  equal  to  the  classi- 
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fication  of  the  eventcount  or  sequencer,  which  is  the  same 
as  that  of  the  segment.  Otherwise,  the  CLASS_GE  function  is 
called  to  verify  that  the  process  has  read  access.  If  the 
appropriate  security  check  is  unsuccessful,  an  error  code  is 
returned  by  CON VERT_AND_VEBIFY .  Otherwise,  the  segment  han¬ 
dle  is  returned  along  with  a  success  code  of  "succeeded"  in¬ 
dicating  that  the  user  process  possesses  the  necessary  se¬ 
curity  clearance  to  complete  execution  of  the  extended 
instr uction . 

2 .  Read 

Frocedure  READ  ascertains  the  current  value  of  a  user 
specified  eventcount  and  returns  its  value  to  the  caller. 
The  input  parameters  to  READ  are  a  segment  number  and  an 
instance  (viz.,  an  event  number).  CONVERT_AND_VERIFY  is  in¬ 
voked  with  a  "read"  access  request  to  obtain  the  segment's 
handle  and  necessary  verification.  "Read"  access  is  suffi¬ 
cient  for  this  operation  as  it  only  requires  observation  of 
the  current  eventcount  value  and  performs  no  data  modifica¬ 
tion.  If  verification  is  successful,  procedure 
M.'l_READ_EYENTCOUNT  is  called  to  obtain  the  eventccunt  value. 

3 .  Ticket 

Procedure  TICKET  returns  the  current  sequencer  value  for 
the  segment  specified  by  the  user.  CQKVERT_AND_VERIFY  is 
called  with  a  request  for  write  access  to  obtain  verifica- 
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tion  and  the  segment  handle.  Write  access  is  required  be¬ 
cause  once  the  sequencer  value  is  read  in  must  be  increment¬ 
ed  in  anticipation  of  the  next  ticket  request.  Once  verifi¬ 
cation  is  complete,  MM_TICKET  is  invoked  to  obtain  the  se¬ 
quencer  value  that  is  returned  to  the  user  process.  It  is 
noted  that  every  call  to  TICKET  for  a  particular  segment 
number  will  return  a  unique  and  time  ordered  sequencer  va¬ 
lue.  This  is  because  the  sequencer  value  may  only  be  read 
within  MM_TICKET  while  the  G_AS T  is  locked,  thereby  prevent¬ 
ing  simultaneous  read  operations.  Futhermore,  once  the  se¬ 
quencer  value  is  read  it  is  incremented  before  the  G_AST  is 
unlocked. 

4.  Await 

Procedure  AWAIT  allows  a  user  process  to  block  itself 
until  some  specified  event  has  occurred.  The  parameters  to 
AWAIT  include  a  segment  number  and  instance,  which  identify 
a  particular  event,  and  a  user  specified  value  which  identi¬ 
fies  a  particular  occurrence  of  the  event.  Verification  of 
read  access  and  a  pointer  to  the  segment's  handle  is  ob¬ 
tained  from  procedure  CONVERT_AND_VERIF Y .  Procedure 
TC_A WAIT  is  invoked  to  effect  the  actual  waiting  for  the 
event  occurrence.  TC_AWAIT  wrll  not  return  to  AWAIT  until 
the  requested  event  has  occurred.  It  is  noted  that  AWAIT 
makes  no  assumptions  about  the  event  value  specified  by  the 
user.  Therefore,  the  Kernel  cannot  guarantee  that  the  event 
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specified  by  the  user  will  ever  occur;  this  is  the  responsi¬ 
bility  of  other  cooperating  user  processes. 

5.  Advance 

Procedure  ADVANCE  allows  a  user  process  to  broadcast  the 
occurrence  of  some  event.  This  is  accomplished  by  incre¬ 
menting  the  value  of  the  eventcount  associated  with  the 
event  that  has  occurred.  The  parameters  to  ADVANCE  include 
a  segment  number  and  instance  which  identify  a  particular 
event.  The  calling  process  must  have  write  access  to  the 
identified  segment  as  modification  of  the  eventcount  is  re¬ 
quired.  Verification  of  write  access  and  a  pointer  to  the 
segment's  handle  is  obtained  through  procedure 
C0NVEBT_AND_V2R IP Y.  Procedure  TC_ADV  ANCE  is  invoked  to  per¬ 
form  the  actual  broadcasting  of  event  occurrence. 

E.  TRAFFIC  controller  module 

The  primary  functions  of  the  Traffic  Controller  module 
are  user  process  scheduling  and  support  of  the  inter-process 
communication  mechanism.  The  Traffic  Controller  is  invoked 
ty  the  occurrence  of  a  virtual  preempt  interrupt  and  by  the 
Event  Manager  and  the  Segment  Manager  through  the  extended 
instruction  set:  TC_Advance,  TC_Await,  Process_Class,  ar.d 

Get_DBR_NUMBER.  The  Traffic  Controller  module  is  comprised 
of  nine  procedures.  Four  of  these  procedures  represent  the 
extended  instruction  set  of  the  Traffic  Controller.  A  ae- 
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tailed  discussion  of  six  of  the  procedures  contained  in  the 
Traffic  Controller  nodule  is  presented  below.  The  regaining 
three  procedures  (viz.,  TC_INIT,  CREATE_PROCESS ,  and 
CREATE_KST)  were  described  in  chapter  three.  The  PLZ/ASU 
assembly  language  source  code  listings  for  the  Traffic  Cont¬ 
roller  module  is  provided  in  Appendix  B. 

1 •  TC  Getvork 

Procedure  TC_GETWORK  provides  the  mechanism  for  user 
process  scheduling.  The  input  parameters  to  TC_GETWORK  are 
the  VP  ID  of  the  virtual  processor  to  which  a  process  will 
be  scheduled  and  the  logical  CPU  number  to  which  the  virtual 
processor  belongs.  The  determination  of  which  process  to 
schedule  is  made  by  a  looping  mechanism  that  finds  the  first 
"ready"  process  on  the  ready  list  associated  with  the  cur¬ 
rent  logical  CPU  number.  Processes  appear  in  the  ready  list 
by  order  of  priority.  This  looping  mechanism  is  required  as 
both  "running"  and  "ready"  processes  are  maintained  on  the 
ready  list.  This  ready  list  structure  was  chosen  to  simpli¬ 
fy  the  algorithm  provided  in  procedure  TC_Advance.  If  a 
ready  process  is  found,  its  state  is  changed  to  "running" 
and  its  process  ID  (viz.,  the  APT  entry  number)  is  inserted 
in  the  running  list  entry  associated  with  the  current  virtu¬ 
al  processor.  Procedure  SWAP_VDBR  is  then  invoiced  in  the 
Inner  Traffic  Controller  to  effect  the  actual  process 
switch.  If  a  ready  process  was  not  found  (viz.,  the  ready 
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list  was  empty  or  comprised  solely  of  "running  processes") , 
o h en  the  running  list  entry  associated  with  the  current  vir— 
tual  processor  is  marked  with  the  constant  "Idle_Proc"  and 
procedure  IDLE  is  invoked  in  the  Inner  Traffic  Controller. 

2.  TC  Await 

The  primary  function  of  TC_AWAIT  is  the  determination  of 
whether  some  user  specified  event  has  occurred.  If  the 
event  has  occured,  control  is  returned  to  the  caller.  Oth¬ 
erwise,  the  process  is  blocked  and  another  process  is  sche¬ 
duled.  The  input  parameters  to  TC_AWAIT  are  a  pointer  to  a 
segment  handle,  an  instance  (event  number) ,  and  a  user  spe¬ 
cified  eventcount  value.  TC_A WAIT  initially  locks  the  Ac¬ 
tive  Process  Table  and  obtains  the  current  value  of  the  ev¬ 
entcount  in  question  by  calling  procedure 
MM_READ_EVENTCOUNT .  The  determination  of  event  occurrence 
is  made  by  comparing  the  user  specified  eventcount  value 
with  the  current  eventcount.  If  the  user  value  is  less  than 
or  equal  to  the  current  eventcount,  the  awaited  event  has 
occurred  and  control  is  returned  to  the  caller.  Otherwise, 
the  awaited  event  has  net  yet  occurred  and  the  process  must 
be  blocked. 

If  the  process  is  to  be  blocked,  procedure  RUNNING_VP  is 
invoked  to  ascertain  the  VP  ID  of  the  virtual  processor 
bound  to  the  process.  The  process*  ID  (viz.,  APT  entry  num¬ 
ber)  is  then  read  from  the  running  list. 
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The  input  parame- 


tecs  to  TC_  A  W AIT  (viz..  Handle,  Instance,  and  Value)  are 
then  stored  in  the  Event  Data  portion  of  the  process'  APT 
entry.  The  process  is  removed  from  its  associated  ready 
list  by  redirecting  the  appropriate  linking  threads  (poin¬ 
ters)  .  Once  removed  from  the  ready  list,  the  process  is 
threaded  into  the  blocked  list  and  its  state  changed  to 
"blocked"  by  invocation  of  the  library  function  LIST_INSERT. 
Procedure  TC_GETWORK  is  then  called  to  schedule  another  pro¬ 
cess  for  the  current  virtual  processor. 

3.  TC  Advance 

The  primary  purpose  of  TC_AD VANCE  is  the  broadcasting 
of  some  event  occurrence.  This  entails  incrementing  the  ev- 
entcount  associated  with  the  event,  awakening  all  processes 
that  are  waiting  for  the  event,  and  insuring  proper  schedul¬ 
ing  order  by  generating  any  necessary  virtual  preempt  inter¬ 
rupts.  The  high  level  design  algorithm  for  TC_ADVANCE  is 
provided  in  Figure  46.  The  input  parameters  to  TC_ADVANCE 
are  a  pointer  to  a  segment's  handle  and  an  .instance  (event 
number) .  Initially,  TC_ADVANCE  locks  the  APT  to  prevent  the 
possibility  of  a  race  condition.  The  eventcount  identified 
by  the  input  parameters  is  then  incremented  by  calling 
Mfl_ADVANCE.  MM_ADV ANCE  returns  the  new  value  of  the  event- 
count.  Once  the  eventcount  has  been  advanced,  TC_ADVANCE 
awakens  all  processes  awaiting  this  event  occurrence.  This 
is  accomplished  by  checking  all  processes  that  are  currently 


228 


in  the  blocked  list. 


The  process'  HANDLE  and  INSTANCE  en¬ 


tries  are  compared  with  the  handle  and  instance  identifying 
the  current  event.  if  they  are  the  same,  then  the  process 
is  awaiting  some  occurrence  of  the  current  event.  In  such  a 
case,  the  process'  VALUE  entry  in  the  APT  is  compared  with 
the  current  value  of  the  eventcount.  if  the  process'  VALUE 
is  less  than  or  equal  to  the  current  eventcount  value,  the 
awaited  event  has  occurred  and  the  process  is  removed  from 
the  blocked  list  and  threaded  into  the  appropriate  ready 
list  by  the  library  function  LIST_INSEfiT. 

Once  the  blocked  list  has  been  checked,  it  is  necessary 
to  reevaluate  each  ready  list  to  insure  that  the  highest 
priority  processes  are  running.  It  is  relatively  simple  to 
determine  if  a  virtual  preempt  interrupt  is  necessary,  how¬ 
ever,  it  is  considerably  more  difficult  to  determine  which 
virtual  processor  should  receive  the  virtual  preempt.  To 
assist  in  this  evaluation,  a  "count"  variable  (number  of 
preempts  needed?  is  zeroed  and  a  preempt  vector  is  created 
on  the  Kernel  stack  with  an  entry  for  every  virtual  proces¬ 
sor  associated  with  the  logical  CPU  being  evaluated.  Ini¬ 
tially,  every  entry  in  the  preempt  vector  is  marked  "true" 
indicating  that  its  associated  virtual  processor  is  a  candi¬ 
date  for  preemption.  Once  the  preempt  vector  is  initial¬ 
ized,  the  first  "n"  processes  on  the  ready  list  (where  n 
equals  the  number  of  VP's  associated  with  the  current  logi¬ 
cal  CPU)  are  checked  for  a  determination  of  their  state.  If 
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TC_ADV  ANCE  Procedure  (HANDLE,  INSTANCE) 
Begin 

!  Get  new  eventcount  l 

COUNT  :=  MM_ADV  ANCE  (HANDLE,  INSTANCE) 

Call  W  AIT_LOCK  (APT) 

!  Wake  up  processes  ! 

PROCESS  ;=  BLOCKED_LIST_H EAD 

Do  while  not  end  of  BLOCKED_LIST 
If  (PROCESS. HANDLE  =  HANDLE)  and 

(PROCESS. INSTANCE  =  INSTANCE)  and 
(PROCESS. COUNT  <=  COUNT) 
then 

Call  LIST_INSERT (READY  LIST) 
end  if 

PROCESS  :=  PROCESS. NEXT_PROCESS 
end  do 

!  Check  all  ready  lists  for  preempts  I 
LOG ICAL_CPU_NO  :=  1 

Do  while  LOG ICAL_CPU_NO  <=  #NR_CPU 
!  Initialize  preempt  vector  I 
V P_ID  :=  PIRST_VP  (LOGIC  AL_CPU_NO) 

DO  for  LOOP  :=  1  to  NR_VP (LOGICAL_CPU_NO 
RUNNING_LIST[VP_ID]. PREEMPT  :=  #TRUE 

VP_ID  :=  VP_ID  ♦  1 
end  do 

i  Find  preempt  candidates  I 
CANDIDATES  :=  0 

PROCESS  :=  READY_LIST_HEAD (LOGICAL_CPU_NO) 


Figure  46:  TC_ADVANCE  Algorithm 
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VP_ID  :=  FIRST_VP  (LOGICAL_CPU_NO) 

Do  (for  CYCLE  =  1  to  NE_VP  (LOGICAL_CPU_ NO)  and 
not  end  of  READY_LIST (LOGICAL  CPU  NO) 

If  PROCESS  =  #RUNNING 
then 

RUNNING_LIST[ VP_ID]. PREEMPT  :=  #FALSE 
else 

CANDIDATES  :=  CANDIDATES  +  1 
end  if 

VP_ID  :=  VP_ID  *  1 
PROCESS  :=  PROCESS. NEXT_PROCESS 
end  do 

!  Preempt  appropriate  candidates  ! 

VP_ID  :=  FIRST_VP  (LGGICAL_CPU_NO) 

Do  for  CHECK  :=  1  to  NR_VP (LOGICAL_CPU_NO) 

If  <RUNNING_LIST[  YP_ID]. PREEMPT  =  #TR  UE)  and 
(CANDIDATES  >  G)  ~ 
then 

Call  SET_PREEMPT  (VP_ID) 

CANDIDATES  :  =  CANDIDATES  -  1 
end  if 

VP_ID  :=  VP_ID  +  1 
end  do 

LOGICAL_CPU_NO  :  -=  LOGICAL_CPU_NO  +  1 

end  do 

Call  UNLOCK  (APT) 

Ret  urn 

End  TC  ADVANCE 


Figure  46:  IC_ADVANCE  Algorithm  (Continued) 
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a  process  is  found  to  be  ''running"  then  it  should  not  be 
preempted  as  processes  appear  in  the  ready  list  in  order  of 
priority.  When  a  running  process  is  found,  its  associated 
entry  in  the  preempt  vector  is  marked  "false."  If  a  process 
is  encountered  in  the  "ready"  state  then  it  should  be  run¬ 
ning  and  the  "count"  variable  is  incremented.  When  the 
first  "n"  processes  have  been  checked  or  when  we  reach  the 
end  of  the  current  ready  list  (whichever  comes  first)  ,  the 
entries  in  the  preempt  vector  are  "popped"  from  the  stack. 
If  an  entry  from  the  preempt  vector  is  found  to  be  "true", 
this  indicates  that  its  associated  virtual  processor  is  a 
candidate  for  preemption  since  it  is  either  bound  to  a  lover 
priority  process,  or  it  is  "idle."  In  such  a  case,  the 
"count"  variable  is  evaluated  to  determine  if  the  virtual 
processor  associated  with  the  vector  entry  should  be 
preempted.  If  the  count  exceeds  zero,  a  virtual  preempt  in¬ 
terrupt  is  sent  to  the  VP  and  the  count  is  decremented. 
Otherwise,  no  preempt  is  sent  as  there  is  no  higher  priority 
process  awaiting  scheduling. 

This  preemption  algorithm  is  completed  for  every  ready 
list  in  the  Active  Process  Table.  Once  all  ready  lists  hcive 
been  evaluated,  the  APT  is  unlocked  and  control  is  returned 
to  the  caller.  It  is  noted  that  it  is  not  necessary  to  in¬ 
voke  TC_GET WORK  before  exiting  ADVANCE.  If  the  current  VP 
requires  rescheduling,  it  will  have  received  a  virtual 
preempt  interrupt  from  the  preemption  algorithm.  If  this 
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has  occurred,  the  VP  will  be  rescheduled  when  its  running 
process  attempts  to  leave  the  Kernel  domain  and  the  virtual 
preempt  interrupts  are  unmasked. 

4 .  Virtual  Preempt  Handler 

V I3TU A L_PREEMPT_ HANDLER  is  the  interrupt  handler  for 
virtual  preempt  interrupts.  The  entry  address  of 
VIRTUAL_PREEMPT_HANDLER  is  maintained  in  the  virtual  inter¬ 
rupt  vector  located  in  the  Inner  Traffic  Controller.  3nce 
invoked,  the  handler  locks  the  Active  Process  Table  and  det¬ 
ermines  which  virtual  processor  is  being  preempted  by  call¬ 
ing  RUNNING_VP.  The  process  running  on  the  preempted  VP  is 
then  set  to  the  "ready"  state  and  TC_GETWORK  is  invoked  to 
reschedule  the  virtual  processor.  When  IC_GETWORK  returns 
to  VIRTUAL_PREEMPT_HANDLER,  the  APT  is  unlocked  and  a  virtu¬ 
al  interrupt  return  is  executed.  This  return  is  simply  a 
jump  to  the  point  in  the  hardware  preempt  handler  where  the 
virtual  interrupts  are  unmasked.  This  effects  a  virtual  in¬ 
terrupt  return  instruction. 

5.  Remaining  Procedures 

The  remaining  two  procedures  in  the  Traffic  Controller 
module  represent  the  extended  instructions:  ?ROCESS_CL ASS 
and  GET_DBR_N UMBER.  Both  procedures  lock  the  Active  Process 
Table  and  call  RUNNING_VP  to  determine  which  virtual  proces¬ 
sor  is  executing  the  current  process.  The  process  ID  (viz.. 
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APT  entry  Number)  is  then  extracted  from  the  running  list. 
PROCESS _CLAS3  reads  and  returns  the  current  process*  securi¬ 
ty  access  classification  from  the  APT.  GET_DBR_NUMBER  reads 
and  returns  the  current  process*  DBE  handle.  It  should  be 
noted  that  in  general  the  DBE  number  provided  by  procedure 
GET_DBR_NUMBER  is  only  valid  while  the  APT  is  locked.  Par¬ 
ticularly,  in  the  current  SASS  implementation,  the  Segment 
Manager  invokes  GET_DBR_NOMBER  and  then  passes  the  obtained 
DBE  number  to  the  Distributed  Memory  Manager  for  utilization 
at  that  level.  In  a  more  general  situation,  the  process  as¬ 
sociated  with  the  DBR  number  may  have  been  unloaded  before 
the  DBR  number  was  utilized,  thus  making  it  invalid.  This 
problem  does  not  arise  in  SASS  as  all  processes  remain  load¬ 
ed  for  the  life  of  the  system. 

C.  DISTRIBUTED  MEIJORJ  MANAGER  MODULE 

The  Distributed  Memory  Manager  module  provides  an  inter¬ 
face  between  the  Segment  Manager  and  the  Memory  Manager  pro¬ 
cess,  manipulates  event  data  in  the  Global  Active  Segment 
Table  (G_AS T) ,  and  dynamically  allocates  available  memory. 
A  detailed  description  of  the  Distributed  Memory  Manager  in¬ 
terface  to  the  Memory  Manager  process  was  presented  by  Wells 
[20].  The  remaining  extended  instruction  set  is  discussed 
in  detail  below.  The  complete  PLZ/ASM  source  listings  for 
the  Distributed  Memory  Manager  module  is  provided  in  Appen¬ 
dix  C. 
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MM  Read  Eventcount 

MM_READ_E VENTCOU NT  is  invoked  by  the  Event  Manager  and 
the  Traffic  Controller  to  obtain  the  current  value  of  the 
eventcount  associated  with  a  particular  event.  The  input 
P^£^®®tsrs  to  this  procedure  are  a  segment  handle  pointer 
and  an  instance  (event  Number),  which  together  uniquely 
identify  a  particular  event. 

The  G_AST  is  locked  and  the  entry  offset  of  the  segment 
into  the  G_  AST  is  obtained  from  the  segment's  handle.  The 
instance  parameter  is  then  validated  to  determine  which  ev¬ 
entcount  is  to  be  read.  If  an  invalid  instance  is  speci¬ 
fied,  control  is  returned  to  the  caller  specifying  an  error 
condition.  Otherwise,  the  current  value  of  the  specified 
eventcount  is  read.  The  G_AST  is  then  unlocked,  and  the 
current  eventcount  value  is  returned  to  the  caller. 

2.  MM  Advance 

MM_ADVANCE  is  invoked  by  the  Traffic  Controller  to  re¬ 
flect  the  occurrence  of  some  event.  The  input  parameters  to 
M M_ADVANCE  are  a  pointer  to  a  segment's  handle  and  a  parti¬ 
cular  instance  (event  number)  . 

The  Global  Active  Segment  Table  is  locked  to  prevent  a 
race  condition,  and  the  offset  of  the  segment's  entry  into 
the  G_AST  is  obtained  from  the  segment  handle.  The  instance 
parameter  is  then  validated  to  determine  which  eventcount  is 
to  be  advanced.  If  an  invalid  instance  is  specified,  an  er- 
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cor  condition  is  returned  to  the  caller  and  no  data  entries 
are  affected.  If  the  instance  value  is  valid,  the  appropri¬ 
ate  eventcount  is  incremented,  and  its  new  value  is  re¬ 
turned. 

3 .  MM_Jicket 

MM_TICK ET  is  invoked  by  the  Event  Manager  to  obtain  the 
current  value  of  the  sequencer  associated  with  a  specified 
segment.  Ihe  input  parameter  to  MM_TICKET  is  a  pointer  to  a 
segment's  handle. 

Initially,  MM_TICKET  locks  the  Global  active  Segment  Ta¬ 
ble  to  prevent  a  race  condition.  Next  the  offset  of  the 
segment's  entry  into  the  G_AST  is  obtained  from  the  segment 
handle.  The  current  value  of  the  sequencer  for  the  speci¬ 
fied  segment  is  then  read  and  saved  as  a  return  parameter  to 
the  caller.  The  sequencer  value  is  then  incremented  in  an¬ 
ticipation  of  the  next  ticket  request.  Once  this  is  com¬ 
plete,  the  G_AST  is  unlocked  and  control  is  returned  to  the 
caller. 

4.  MM_aiiocate 

The  MM_ALLOCATE  procedure  provided  in  this  implementa¬ 
tion  is  a  stub  of  the  MM_ALLOCATE  descriced  in  the  Memory 
Manager  design  of  Moore  and  Gary  £5].  The  primary  function 
of  MM_ALLOCATE  is  the  dynamic  allocation  of  fixed  size 
olocks  of  available  memory  space.  It  is  invoked  in  the  cur- 
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rent  implementation  by  the  initialization  routines  in 
BOOTSTRAP_LOADER  and  TC_INIT  for  the  allocation  of  memory 
space  used  in  the  creation  of  the  Kernel  domain  and  Supervi¬ 
sor  domain  stack  segments  and  the  creation  of  the  Known  Seg¬ 
ment  Tables  for  user  processes.  Dynamic  reallocation  of 
previously  used  memory  space  (viz.,  garbage  collection)  is 
not  provided  by  the  MM_ALLOCATE  stub  in  this  implementation. 
All  memory  allocation  required  in  this  implementation  is  for 
segments  supporting  system  processes  that  remain  active,  and 
thus  allocated,  for  the  entire  life  of  the  system.  Memory 
is  allocated  in  blocks  of  256  (decimal)  bytes  of  processor 
local  memory  (on-board  RAM) .  In  this  stub  allocatable  memo¬ 
ry  is  declared  at  compile  time  by  a  data  structure 
(MEM_POOL)  that  is  accessible  only  by  MM_ALLOCATE. 

The  input  parameter  to  Ma_ALLOCATE  is  the  number  of 
blocks  of  requested  memory.  This  parameter  is  converted 
from  a  block  size  to  the  actual  number  of  bytes  requested. 
This  computation  is  made  simple  since  memory  is  allocated  in 
powers  of  two.  The  byte  size  is  obtained  by  logically 
shifting  left  the  input  parameter  eight  tines,  where  eight 
is  the  power  of  two  desired  (viz.  ,  256)  .  Once  the  size  of 
the  requested  memory  is  computed,  it  is  necessary  to  deter¬ 
mine  the  starting  address  of  the  memory  block  (s)  to  be  allo¬ 
cated.  To  assist  in  this  computation,  a  variable 
(NEXT_BLOCK)  is  used  to  keep  track  of  the  next  available 
block  of  memory  in  MEM_POOL.  NEXT_BLOCK,  which  is  initial- 
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ized  as  zero,  provides  the  offset  into  the  memory  oeing  al¬ 
located.  Once  the  starting  address  is  obtained,  the  physi¬ 
cal  size  of  the  oemory  allocated  is  added  to  NEXT_BLOCK  so 
that  the  next  request  for  memory  allocation  will  begin  at 
the  next  free  byte  of  memory  in  MEM_POOL.  This  new  value  of 
NEXT_BLOCK  is  saved  and  the  starting  address  of  the  memory 
for  this  request  is  returned  to  the  caller. 

D.  GA£E  KEEPER  HOPPLES 

The  SASS  Gate  Keeper  provides  the  logical  boundary  bet¬ 
ween  the  Supervisor  and  the  Kernel  and  isolates  the  Kernel 
from  the  system  users,  thus  making  it  tamperproof.  This  is 
accomplished  by  means  of  the  hardware  system/normal  mode  and 
the  software  ring-crossing  mechanism  provided  by  the  Gate 
Keeper.  The  Gate  Keeper  is  comprised  of  two  separate  mo¬ 
dules:  1)  the  USER_GATE  module,  and  2)  the 
KERNEL_GATE_KEEPER  module.  These  modules  are  disjoint,  with 
the  BSER_GATE  module  residing  in  the  Supervisor  domain  and 
the  KEBNEL_GATE_KEEPER  module  residing  in  the  Kernel  domain. 
It  is  important  to  note  that  the  USER_GATE  is  a  separately 
linked  component  in  the  Supervisor  domain  and  is  not  linked 
to  the  Kernel.  The  only  thing  in  common  between  these  two 
modules  is  a  set  of  constants  identifying  the  valid  extended 
instruction  set  which  the  Kernel  provides  to  the  users. 

The  Gate  Keeper  modules  presented  in  this  implementation 
are  only  stubs  as  they  do  not  provide  all  of  the  functions 
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required  of  the  Gate  Keeper.  However,  the  only  task  not 
provided  m  this  implementation  is  the  validation  of  parame¬ 
ters  passed  from  the  Supervisor  to  the  Kernel.  A  detailed 
description  of  this  parameter  validation  design  is  provided 
by  Coleman  £2].  In  the  process  management  demonstration, 
the  Supervisor  stubs  are  written  in  PLZ/ASM  with  all  parame¬ 
ters  passed  by  CP(J  registers.  A  detailed  description  of  the 
Gate  Keeper  modules  and  the  nature  of  their  interfaces  is 
presented  below.  The  PLZ/ASM  source  listings  for  the  two 
Gate  Keeper  modules  are  provided  in  Appendix  D. 

1 •  0§st_Gate  Module 

The  USER_GATE  module  provides  the  interface  structure 
between  the  user  processes  in  the  Supervisor  domain  and  the 
Kernel.  The  0SER_GATE  is  comprised  of  ten  procedures  (viz., 
entry  points)  that  correlate  on  a  one  to  one  basis  with  the 
ten  "user  visible"  extended  instructions  (listed  in  Figure 
10)  provided  by  the  Kernel.  The  only  action  performed  by 
each  of  these  procedures  is  the  execution  of  the  "system 
call"  instruction  (SC)  with  a  constant  value,  identifying 
the  particular  extended  instruction  invoked,  as  the  source 
operand. 

The  SC  instruction  is  a  system  trap  that  forces  the 
hardware  into  the  system  mode  (Kernel  domain)  and  loads  re¬ 
gister  15  with  the  system  stack  pointer  (Kernel  domain 
stack) .  The  current  instruction  counter  value  (IC)  is 
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pushed  onto  the  Kernel  stack  along  with  the  current  CPU  flag 
control  word  (FCW) .  in  addition,  the  system  trap  instruc¬ 
tion  is  pushed  onto  the  Kernel  stack  with  the  upper  byte 
representing  the  SC  instruction  and  the  lower  byte  repre¬ 
senting  the  SC  instruction's  source  operand  (viz.,  the  Ker¬ 
nel  extended  instruction  code) .  Together,  these  operations 
form  an  interrupt  return  (IBET)  frame  as  illustrated  in  Fig¬ 
ure  44.  Once  this  is  complete,  the  FCW  is  loaded  with  the 
FCW  value  found  in  the  System  Call  frame  of  the  Program  Sta¬ 
tus  Area  (viz.,  the  hardware  "interrupt  vector").  The 
structure  of  the  Program  Status  Area  is  illustrated  in  Fig¬ 
ure  47.  The  instruction  counter  is  then  loaded  with  the  ad¬ 
dress  of  the  SC  instruction  trap  handler.  This  value  is 
also  located  in  the  SC  frame  of  the  Program  Status  Area. 
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Figure  47:  Program  Status  Area 
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2 •  Kernel  Gate  Keeper  Module 

The  system  trap  handler  for  the  System  Call  instruction 
is  the  KERN  EL_GATE_KEEPEH .  The  address  of  the 
KERNE L_3 ATE _KEE PER  and  the  Kernel  FCli  value  are  placed  in 
the  System  Call  frame  of  the  Program  Status  Area  by  the 
600TSTRAP_L0ADER  module  during  initialization.  The 
KERNEL_GATS_KEEPER  fetches  the  extended  instruction  code 
from  the  trap  instruction  entry  in  the  IRET  frame  on  the 
Kernel  stack.  This  value  is  then  decoded  by  a  "case"  state¬ 
ment  to  determine  which  extended  instruction  is  to  be  exe¬ 
cuted.  If  the  extended  instruction  code  is  valid,  the  ap¬ 
propriate  Kernel  procedure  is  invoked.  Otherwise,  an  error 
condition  is  set  and  no  Kernel  procedures  are  not  invoked. 
Once  control  returns  to  the  KERNEL_GATE_KEEPER,  the  CPU  re¬ 
gisters  and  normal  stack  pointer  (NSP)  value  are  pushed  onto 
the  Kernel  stack  in  preparation  for  return  to  the  Supervisor 
domain.  It  is  noted  that  this  operation  would  normally  oc¬ 
cur  immediately  upon  entry  into  the  KERNEL_GATE_KEEPER.  In 
this  implementation,  however,  parameter  validation  is  not 
accomplished  and  the  CPU  registers  are  used  to  pass  parame¬ 
ters  to  and  from  the  Kernel  only  for  use  by  the  process  man¬ 
agement  demonstration.  In  an  actual  SASS  environment,  all 
parameters  would  be  passed  in  a  separate  argument  list  and 
the  CPU  registers  would  appear  exactly  the  same  upon  leaving 
the  Kernel  as  they  did  upon  entering  the  Kernel.  This  is 
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important  to  insure  that  no  data  or  information  is  leaked 
from  the  Kernel  by  means  of  the  CPU  registers. 

Control  is  returned  to  the  Supervisor  by  means  of  the 
return  mechanism  in  the  hardware  preempt  handler.  This  me¬ 
chanism  is  utilized  to  preclude  the  necessity  of  building  a 
separate  mechanism  for  the  KERNEL_GATE_KEEPER  that  would  ac¬ 
tually  perform  the  very  same  function.  To  accomplish  this, 
the  KERNEL_GATE_KEEP2R  executes  an  unconditional  jump  to  the 
PREEMPT_RET  label  in  PHYS_PREEMPT_H ANDLER.  This  "jump"  to 
the  hardware  preempt  handler  represents  a  "virtual  IRET"  in¬ 
struction  providing  the  same  function  as  the  virtual  inter¬ 
rupt  return  described  in  the  discussion  of  the  virtual 
preempt  handler.  At  this  point,  the  virtual  preempt  inter¬ 
rupts  are  unmasked,  the  normal  stack  pointer  and  CPU  regis¬ 
ters  are  restored  from  the  stack,  and  control  is  returned  to 
the  Supervisor  by  execution  of  the  IRET  instruction. 

E.  SUMMARY 

The  implementation  of  process  management  functions  for 
the  SAGS  has  been  presented  in  this  chapter.  The  implemen¬ 
tation  was  discussed  in  terms  of  the  Event  Manager,  Traffic 
Controller,  Distributed  Memory  Manager,  and  Gate  Keeper  mo¬ 
dules. 
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Chapter  XXIII 
CONCLUSION 

The  implementation  of  process  management  for  the  securi¬ 
ty  Kernel  of  a  secure  archival  storage  system  has  been  pre¬ 
sented.  The  process  management  functions  presented  provide 
a  logical  and  efficient  means  of  process  creation,  control, 
and  scheduling.  In  addition,  a  simple  but  effective  mechan¬ 
ism  for  inter-process  communication,  based  on  the  eventcount 
and  sequencer  primitives,  was  created.  MorJc  was  also  com¬ 
pleted  in  the  area  of  Kernel  database  initialization  and  a 
Gate  Keeper  stub  to  allow  for  dual  domain  operation. 

The  design  for  this  implementation  was  based  on  the  Si- 
log  Z8001  sixteen  bit  segmented  microprocessor  [22]  used  in 
conjunction  with  the  Zilog  Z80 10  Memory  Management  Unit 
[23].  The  actual  implementation  of  process  management  for 
the  SASS  was  conducted  on  the  Advanced  Micro  Computers 
Am96/4116  MonoBoard  Computer  [1]  featuring  the  AmZ8002  six¬ 
teen  bit  Qon-segmented  microprocessor.  Segmentation  hard¬ 
ware  was  simulated  by  a  software  Memory  Management  Unit  Im¬ 
age. 

This  implementation  was  effected  specifically  to  support 
the  Secure  Archival  Storage  System  (SASS;  [17].  However, 
the  implementation  is  based  on  a  family  of  Operating  Systems 
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[7]  designed  with  a  primary  goal  of  providing  multilevel  in¬ 
formation  security.  The  loop  free  modular  design  utilized 
in  this  implementation  easily  facilitates  any  reguired  ex¬ 
pansion  or  modification  for  other  family  members.  In  addi¬ 
tion,  this  implementation  fully  supports  a  multiprocessor 
design.  While  the  process  management  implementation  appears 
to  perform  correctly,  it  has  not  been  subjected  to  a  formal 
test  plan.  Such  a  test  plan  should  be  developed  and  imple¬ 
mented  before  kernel  verification  is  begun. 

A.  POL LOW  ON  WORK 

There  are  several  possible  areas  in  the  SASS  design  that 
would  be  immediately  suitable  for  continued  research.  In 
the  area  of  hardware,  this  includes,  the  establishment  of  a 
multiprocessor  environment,  hardware  initialization,  and  in¬ 
terfacing  to  the  host  computers  and  secondary  storage. 
Further  work  in  the  Kernel  includes  the  actual  implementa¬ 
tion  of  the  memory  manager  process,  and  the  refinement  of 
the  Gate  Keeper  and  Kernel  intia lization  structures.  The 
implementation  of  the  Supervisor  has  not  been  addressed  to 
date.  Its  areas  of  research  include  the  implementation  of 
the  File  Manager  and  Input/Output  processes,  and  the  final 
design  and  implementation  of  the  SASS-Hosts  protocols. 

Other  areas  that  could  also  prove  interesting  in  rela¬ 
tion  to  the  SASS  include  the  implementation  of  dynamic  memo¬ 
ry  management,  the  support  of  multilevel  hosts,  dynamic  pro- 


245 


cess  creation  and  deletion,  and  the 
constructive  work  to  be  performed  by  the  Idle 


provision 
process . 


Appendix  A 

EVENT  MANAGER  LISTINGS 


Z  8000  ASM  2.02 

LOC  OBJ  CODE  STMT  SOURCE  STATEMENT 

SLISTON  $TTY 

EVE  NT_MGR  MODULE 

CONSTANT 
TRUE 
FALSE 

READ_ACCESS 
WRITE_ACCESS 
SUCCEEDED 
SEGMENT_NOT_KNOWN 
ACCES  S_CLASS_NOT_EQ 

access~class”not!ge 

KST_SEG_NO 
NR_OF_KSEGS 
MAX_NO_KST_EN TRIES 
NOT  KNOWN 


H  _ARR  AY  ARR AY[  3  WORD] 

KST_REC  RECORD 
[MM  HANDLE  H  ARRAY 
SIZE  WORD 

ACCESS_MODE  BYTE 
I N_COR  E  BYTE 

CLASS  LONG 

H_S3G_N0  SHORT_INTEGER 
ENTRY_NU MBER  SHORT_INTEGER] 

EXTERNAL 
KM_TI CKET 

K  M_P.EAD_EV  ENTCOUNT 
TC_ AD VANCE 
TC_AW  AIT 
PROCESS_CL ASS 
CLASS_EQ 
CLASS  J5E 
ITC  GET  SEG  PTR 


PROCEDURE 

PROCEDURE 

PROCEDURE 

PROCEDURE 

PROCEDURE 

PROCEDURE 

PROCEDURE 

PROCEDURE 


=  0 
=  1 
=  0 
=  2 
=  28 
=  33 
=  41 
=  2 
=  10 
=  54 
=  XFF 
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INTERNAL 


0000 


SSECTIO N  EM_KST_DCL 

!  NOTE:  THIS  SECTION  IS  AN  "OVERLAY" 

OR  "FRAME"  OSED  TO  DEFINE  THE 
FORMAT  OF  THE  KST .  NO  STORAGE  IS 
ASSIGNED  BOT  RATHER  THE  KST  IS 
STORED  IN  A  SEPARATELY  OBTAINED 
AREA.  (A  SEGMENT  SET  ASIDE  FOR  IT)  • 

SABS  0 

KST  ARRAY[ HAX_NO_KST_ENTRIES  KST_REC  ] 
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GLOBAL 
$  SECTION 


EM  GLB  PROC 


0000 


READ  PROCEDURE 

i ****************************** 

*  READS  SPECIFIED  EVENTCOUNT  * 

*  AND  RETURNS  IT’S  VALUE  TO  * 

*  THE  CALLER  * 

****************************** 

*  PARAMETERS:  * 

*  B1:  SEGMENT  *  * 

*  R2:  INSTANCE  * 

********  ********************** 

*  RETURNS:  * 

*  RO:  SUCCESS  CODE  * 

*  RR4:  EVENTCOUNT  * 

****************************** i 


ENTRY 

!  SAVE  INSTANCE  ! 


0000 

93F2 

PUSH 

3R15,  R2 

!  "READ 

ACCESS  REQUIRED  ! 

0002 

2102 

LD 

R2,  #READ_ACCESS 

0004 

0001 

i  GET  SEG  HANDLE  &  VERIFY  ACCESS  I 

0006 

5F00 

CALL 

CON VERT_AND_VERIFY  !R1:SEG  * 

0008 

0000' 

R2:REQ.  ACCESS 
RETURNS: 

RO : SUCCES S  CODE 
R1  .-HANDLE  PTE ! 

000A 

0B00 

CP 

RO,  (^SUCCEEDED 

OOOC 

0002 

IF  EQ  ! 

ACCESS  PERMITTED! 

000E 

5E0E 

THEN 

!  READ  EVENTCOUNT! 

0010 

001C* 

’RESTORE  INSTANCE! 

0012 

97F2 

POP 

R2,  3R15 

0014 

5F00 

CALL 

MM_READ_E VENT COUNT  !E1:HPTR 

0016 

0000* 

R2: INSTANCE 
RETURNS: 
ROiSUCCESS  CODE 
RR4: EVENTCOUNT! 

0018 

5E08 

ELSE 

! RESTORE  SP! 

0  0  1 A 

00  IE' 

001C 

97F2 

POP 

R2,  <z»R  1 5 

FI 

00 1  E 

9E08 

RET 

0020 

END  READ 
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0020 


TICKET  PROCEDURE 

I  ******************************* 

*  RETURNS  CURRENT  VALUE  OF  * 

*  TICKET  TO  CALLER  AND  INCRE-  * 

*  M ENTS  SEQUENCER  FOR  NEXT  * 

*  TICKET  OPERATION  * 

******************************* 

*  PARAMETERS:  * 

*  81:  SEGMENT  #  * 

******************************* 

*  RETURNS:  * 

*  RO:  SUCCESS  CODE  * 

*  RR4:  TICKET  VALUE  * 

******************************** 


ENTRY 

!  GET  SEG  HANDLE  S  VERIFY  ACCESS  ! 
!  "WRITE”  ACCESS  REQUIRED  ! 


0020 

0022 

2102 

0000 

LD 

82,  #WRITE_ACCESS 

0024 

0026 

5F00 

0000' 

CALL 

C ON V ERT_ AN D_ VERIFY  ! 

R 1 : SEG  * 

R2: ACCESS 
RETURNS: 
RO:SUCCESS 
R 1  : HANDLE 

0028 
0  02  A 

0B00 

0002 

CP 

IF  EQ 

RO,  tSUCCEEDED 

! ACCESS  PERMITTED! 

002C 

002E 

5E0E 

0038* 

THEN 

!  GET  TICKET  ! 

0030 

0032 

5F00 

0000* 

CALL  MM_TICKET  1H  Is  HANDLE  PTR 

RETURNS: 

RR4: TICKET! 

!  RSTORE  SUCCESS  CODE  ! 

0034 

0036 

0038 

2100 

0002 

9E08 

LD 

FI 

RET 

RO,  tSUCCEEDED 

003A 


END  TICKET 


REQ 

CODE 

PTR! 
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003A  AWAIT  PROCEDURE 

I  ***********************  ******** 

*  CURRENT  EVENTCOUNT  VALUE  IS  * 

*  COMPARED  TO  USER  SPECIFIED  * 

*  VALUE.  IF  USER  VALUE  IS  * 

*  GREATER  THAN  CURRENT  EVENT-  * 

*  COUNT  VALUE  THEN  PROCESS  IS  * 

*  "BLOCKED"  UNTIL  THE  DESIRED  * 

*  EVENT  OCCURS.  * 

******************************* 

*  PARAMETERS:  * 

*  R 1 :  SEGMENT  #  * 

*  R2 :  INSTANCE  (EVENT  #)  * 

*  RR4 :  SPECIFIED  VALUE  * 

******************************* 


*  RETURNS:  * 

*  RO:  SUCCESS  CODE  * 

******************************* i 


ENTRY 

!  SAVE  DESIRED  EVENTCOUNT  VALUE  ! 


003  A 

91F4 

PUSHL 

5)R15,  RR4 

!  SAVE 

INSTANCE  ! 

003C 

93F2 

PUSH 

3R15,  R2 

!  "READ"  ACCESS  REQUIRED  ! 

003E 

2102 

LD 

R2,  #READ_ACCESS 

0040 

0001 

!  GET 

SEG  HANDLE  &  VERIFY  ACCESS  ! 

0042 

5F00 

CALL 

CON VERT_AND_V  ERIFY  !R1:SEG  * 

0044 

0000* 

R2 : ACCESS  REQ 
RETURNS: 
RO:SUCCESS  CODE 
R 1 : HANDLE  PTR ! 


0046  0B00  CP  RO,  ^SUCCEEDED 

0048  0002 

IF  EQ  J  ACCESS  PERMUTED  ! 

004A  5E0E  THEN  !  AWAIT  EVENT  OCCURRENCE  I 

004C  005 A' 


004E  97F2 

0050  95F4 
0052  5F00 
0054  0000* 


!  RESTORE  INSTANCE  ! 
pop  R2,  aai5 

!  RESTORE  SPECIFIED  VALUE  ! 
POPL  RR4 ,  3S  15 

CALL  TC  AWAIT  !R1: HANDLE  PTR 


R2: INSTANCE 
RR4 : VALUE 
RETURNS: 

RO: SUCCESS  CODE! 
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0056  5E08 
0058  005E’ 
005A  95F4 
005C  97F2 

0 05E  9E08 
0060 


ELSE  ! RESTORE  STACK ! 

POPL  RR4 ,  SR15 
POP  R2 ,  SR  15 
FI 
RET 

END  AWAIT 
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0060  ADVANCE  PROCEDURE 

J  ******************************* 

*  SIGNALS  THE  OCCURRENCE  OF  * 

*  SOME  EVENT.  EVENTCOUNT  IS  * 

*  INCREMENTED  AND  THE  TRAFFIC  * 

*  CONTROLLER  IS  INVOKED  TO  * 

*  AWAKEN  ANY  PROCESS  AWAITING  * 


*  THE  OCCURRENCE.  * 

******************************* 

*  PARAMETERS:  * 

*  R1 :  SEGMENT  #  * 

*  R2 :  INSTANCE  (EVENT  #)  * 

******************************* 

*  RETURNS:  * 

*  RO:  SUCCESS  CODE  * 


************** *****************  i 


ENTRY 

!  SAVE  INSTANCE  ! 
0060  93F2  PUSH  3R15,  R2 


0062  2102 
0064  0000 
0066  5F00 
0068  0000' 


006 A  0300 
006C  0002 

006E  5E0E 
0070  007C 

0072  97F2 


S  get  SEG  HANDLE  6  VERIFY  ACCESS  i 
i  "WRITE”  ACCESS  REQUIRED  ! 

LD  R2 ,  #WRITE_ACCESS 

CALL  C ON VERT_ AN D_ VERIFY  !R1:SEG  t 

R2: ACCESS  REQ 
RETURNS: 
RO:SUCCESS  CODE 
R 1 : HAN DLE  PTR! 

CP  RO,  ^SUCCEEDED 

IF  EQ  l  ACCESS  PERMITTED  ! 

THEN  !  ADVANCED  EVENTCOUNT  i 

!  RESTORE  INSTANCE  ! 

POP  R2,  3R15 


0074  5F00 
0076  0000* 


0078  5E08 
007A  007E ' 
007C  97F2 

007E  9E08 
0080 


CALL  TC_AD VANCE  ! R 1 : HANDLE  PTR 

R2 : INSTANCE 
RETURNS: 

RO  :SUCCESS  CODE! 
ELSE  ! RESTORE  STACK! 

POP  R2,  a>R  15 
FI 
RET 

END  ADVANCE 
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I NTERNAL 

SSECTION  EM  INT  PROC 


0000 

CON  7ERT_AND_VERIFY  PROCEDURE 

» *************************************** 

*  CONVERTS  SEGMENT  NUMBER  TO  KST  INDEX* 

*  AND  EXTRACTS  SEGMENT'S  HANDLE  FROM  * 

*  KST.  IF  SUCCESSFUL,  THEN  ACCESS  * 

*  CLASS  OF  SUBJECT  IS  CHECKED  AGAINST  * 

*  ACCESS  CLASS  OF  OBJECT  TO  INSURE  * 

*  THAT  ACCESS  IS  PERMITTED.  * 

*************************************** 

*  PARAMETERS:  * 

*  R1:  SEGMENT  NUMBER  * 

*  R2 :  ACCESS  REQUESTED  ♦ 

*************************************** 

*  RETURNS:  * 

*  RO:  SUCCESS  CODE  * 

*  81:  HANDLE  POINTER  * 

*************************************** i 

0000  93F2 

ENTRY 

!  SAVE  REQUESTED  ACCESS  ! 

PUSH  SR  15  ,  R2 
!  GET  SEGMENT  HANDLE  ! 

0002  5F00 
0004  0062' 

CALL  GET_HAN DLE  !R1:SSG  # 

RETURNS: 

RO:SUCCESS  CODE 

0006  OBOO 

C 008  0002 

R4  : HANDLE  PTR 

R5:CLASS  PTR! 

CP  RC,  #SUCCEEDED 

COOA  5EOE 
OOOC  005E' 

IF  EQ  !  SEGMENT  IS  KNOWN  ! 

THEN  !  VERIFY  ACCESS  ! 

OOOE  91F4 

!  SAVE  HANDLE  S  CLASS  PTR  ! 

PUSHL  SR  15,  RR4 
!  GET  SUBJECT'S  SAC  ! 

0010  5FOO 
0012  0000* 

CALL  P ROC ESS_C LASS  ! RETURNS: 

0014  95F0 

RR2 : PROC  CLASS! 

!  RETRIEVE  SEG  CLASS  POINTER  ! 

POPL  RRO ,  SR 1 5 
!  GET  SEGMENT’S  CLASS  ! 

0016  1414 

LDL  ER4,  SRI 

!  RETRIEVE  REQUESTED  ACCESS  ! 

0018  97F1 

POP  HI,  SR  15 

!  SAVE  HANDLE  POINTER  ! 

00 1  A  93F0 

PUSH  SR  15,  RO 
!  CHECK  ACCESS  CLEARANCE  ! 

001C  0301 

00 1 E  0000 

CP  R1,  #  WRITE_ACC  ESS 

IF  EQ  !  WRITE  ACCESS  REQUESTED  ! 

254 


0020 

5E0E 

THEN 

0022 

0040' 

0024 

5F00 

CALL 

CLASS_EQ  ! RR2 : PROCESS  CLASS 

0026 

0000* 

RR4: SEGMENT  CLASS 
RETURNS: 

HI:  CONDITION  CODE 

0028 

0B0  1 

CP 

R1,  #FALSE 

002A 

0000 

IF  EQ 

! ACCESS  NOT  PERMITTED* 

002C 

5E0E 

THEN 

002E 

0038' 

0030 

2100 

LD 

RO,  #ACCESS_CLASS_NOT_EQ 

0032 

0021 

0034 

5E08 

ELSE 

! ACCESS  PERMITTEDI 

0036 

003C’ 

0038 

2100 

LD 

RO,  ^SUCCEEDED 

003A 

0002 

FI 

003C 

5E08 

ELSE  ! 

READ  ACCESS  REQUESTED  ! 

003E 

0058' 

0040 

5F00 

CALL 

CLASS_GE  ! RR 2 : PROCESS  CLASS 

0042 

0000* 

RR4 :SEGMENT  CLASS 
RETURNS: 

R1  CONDITION  CODE! 

0044 

OBO  1 

CP 

R 1 ,  *F  ALSE 

0046 

0000 

IF  EQ 

! ACCESS  NOT  PERMITTED! 

0048 

5E0E 

THEN 

0  04  A 

0054’ 

0  04C 

2100 

LD 

RO,  #ACCESS_CLASS_NOT_GE 

004E 

0029 

0050 

5E08 

ELSE 

! ACCESS  PERMITTED! 

0052 

0058' 

0054 

2100 

LD 

RO,  #SUCCEEDED 

0056 

0002 

FI 

FI 

!  RETRIEVE  HANDLE  POINTER  ! 

0058 

97F1 

POP  R1 

,  dR  15 

005  A 

5E08 

ELSE 

005C 

0060* 

!  RESTORE  STACK  ! 

005E 

97F2 

POP  R2 

:,  3R15 

FI 

0060 

9E08 

RET 

0062 

END  CONV ERT_AND_VERIF Y 
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0062 


0062 

0064 

0066 

0068 

006A 

006C 

006E 

0070 

0072 

0074 

0076 

0078 

007A 

007C 

007E 

0080 

0082 

0084 


0086 

0088 

008A 

008C 

008E 

0090 

0092 

0094 


GET_H ANDLE  PROCEDURE 

; ******************************* 

*  CONVERTS  SEGMENT  NUMBER  TO  * 

*  KST  INDEX  AND  DETERMINES  IF  * 

*  SEGMENT  IS  KNOWN.  IF  KNOWN  * 

*  POINTER  TO  SEGMENT  HANDLE  * 

*  AND  POINTER  TO  SEGMENT  CLASS* 


*  ARE  RETURNED.  * 

******************************* 

*  PARAMETERS:  * 

*  HI:  SEGMENT  NUMBER  * 

***********************  ******** 

*  RETURNS:  * 

*  RO:  SUCCESS  CODE  * 

*  R4:  HANDLE  POINTER  * 

*  R5:  CLASS  POINTER  * 

*******************************  f 


ENTRY 

!  CONVERT  SEGMENT  ♦  TO  KST  INDEX 


0301 
000  A 

SUB 

B1, 

#NR_OF_KSEGS 

!  VERIFY  KST  INDEX  ! 

2100 

LD 

RO, 

♦SUCCEEDED 

0002 
0B0  1 
0000 

CP 

HI, 

#0 

IF  LE 

! INDEX  NEGATIVE! 

5E0A 
007  A  * 

THEN 

2100 

001C 

LD 

RO 

,  # SEG  ME  NT_NOT_KNOWN 

5  EOS 

ELSE 

.'INDEX  POSITIVE! 

0086* 
0B0  1 

CP 

R 1 

,  #  MAX_NO_KS  T_EN TRIES 

0036 

IF 

GT  ! 

EXCEEDS  MAXIMUM  INDEX! 

5E02 

THEN  ! 

INVALID  INDEX! 

0086' 

2100 

LD 

RO,  #SEG  MENT_NOT_KNOWN 

001C 

FI 

FI 

0B00 

0002 

CP 

RO, 

♦SUCCEEDED 

IF  EQ 

! INDEX  VALID! 

5E0E 

OOBE* 

THEN 

t 


!  SAVE  KST  INDEX  ! 

93F1  PUSH  5>R15,  R1 

I  GET  KST  ADDRESS  ! 

2101  LD  R1,  ♦  KST_S  EG  NO 

0002 

5F00  CALL  ITC  GET  SEG  PTE  !R1:KST  SEG  NO 
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0096  0000* 


RETURNS: 

R0 : KST  ADDR! 

I  RETRIEVE  KST  INDEX  *  i 


0098 

97F3 

POP 

R3 ,  SR  15 

!  CONVERT  KST  INDEX  #  TO  KST 

009A 

1902 

MULT 

RR2,  tSIZEOF  KST_REC 

00  9C 

0010 

!  COMPOTE  KST  ENTRY  ADDRESS  ! 

009E 

8103 

ADD 

R3 ,  RO 

i  SEE 

IF  SEGMENT  IS  KNOWN  ! 

0  0  AO 

4D3  1 

CP 

KST.M_SEG_NO  (R3)  ,  #NOT_ 

00A2 

OOOE 

0  0  A4 

OOFP 

IF  EQ 

!  SEGMENT  NOT  KNOWN ! 

00A6 

5E0E 

THEN 

00A8 

00B2' 

OOAA 

2100 

LD 

RO,  #SEGMENT_NOT_KNOWN 

00  AC 

001C 

OOAE 

5S08 

ELSE 

•SEGMENT  KNOWN! 

OOBO 

OOBE* 

00B2 

2100 

LD 

RO,  #SUCCEEDED 

00B4 

0002 

!  GET  HANDLE  POINTER  ! 

00B6 

7634 

LDA 

R4 ,  KST. MM_HANDLE (R3) 

00B8 

0000 

!  GET  CLASS  POINTER  ! 

OOBA 

7635 

LDA 

R5,  KST.  CLASS  (R3) 

00  BC 

000  A 

FI 

FI 

OOBE 

9E08 

RET 

OOCO 

END  GET_ 

HANDLE 

END  EVENT 

_MGR 
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Appendix  B 

TRAFFIC  CONTBOLLEB  LISTINGS 

Z8000ASM  2.02 

LOC  OBJ  CODS  STMT  SOURCE  STATEMENT 

3LISTON  3TTY 
TC  MODULE 


CONSTANT 


j  ** ******  SYSTEM  PARAMETERS  ********  • 


NR_PROC 
VP_NR 
NR~CPU 
NR  KST 


4 

2 

2 

54 


********  SYSTEM 
RUNNING 
READY 
BLOCKED 
IDLE_PROC 
NIL 

INVALID 
KERNEL  STACK 


USER_STACK 
KST  SEG 
KST~L IMIT 
US  ER_FCW 
WRITE 

!  INDICATES 
SECURITY  CLASS! 
SYSTEM_LOW 
STK_OFFSET 
REMOVED 
TRUE 
FALSE 
SUCCEEDED 


CONSTANTS  ********  » 
0 
1 

2 

XDDDD 
5SFFFF 
XEEEE 
1 
3 
2 
1 

X1800 
0 

LOWEST  SYSTEM 


0 

XFF 

XABCD 

1 

0 

2 


TYPE 
AP_PTR 
V  E'_PTR 
ADDRESS 
H  ARRAY 


WORD 

WORD 

WORD 

ARRAY[3  WORD] 
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AP_TABLE  RECORD 
[ NEXT_AP 
DBR 
SAC 
PRI 
STATE 
AFFINITY 
VP_ID 
HANDLE 
INSTANCE 
VALUE 
FILL_2 

] 


AP  PTR 

WORD 

LONG 

INTEGER 

INTEGER 

WORD 

V  P_PTR 

H_ARRAY 

WORD 

LONG 

ARR  AY[  2  WORD] 


RUN_ARRAY 
RDY_ARR AY 
A  P_DATA 
VP_DATA 
[ NR_V  P 
FIRST 

] 


ARRAY[ VP_NR  AP_PTR  ] 
ARRAYf  NR_CPU  AP_PTR ] 
ARRAY[ NR  PROC  AP_TABLE] 
RECORD 

ARR AY[  N  R_CPU  WORD] 
ARRAY[ NR_CPU  VP_PTR  ] 


KST_REC 
[  MK  HANDLE 
SIZE 
ACCESS 
IN_CORE 
CLASS 
M_SEG.NO 
ENT  RY_NU  M 

] 


RECORD 

H_ARR AY 

WORD 

BYTE 

BYTE 

LONG 

SHORT_I NT EG  ER 
SHORT  INTEGER 


EXTERNAL 


K.LOCK 

PROCEDURE 

K_U  NLOCK 

PROCEDURE 

SET  PREEMPT 

PROCEDURE 

SWAP  VDBR 

PROCEDURE 

IDLE 

PROCEDURE 

R  UN  NI NG_ VP 

PROCEDURE 

CRE ATE.INT.VEC 

PROCEDURE 

LIS  T_I  NS  ERT 

PROCEDURE 

ALLOCATE  MMU 

PROCEDURE 

M  M_ ALLGC  ATE 

PROCEDURE 

UPDATE  MMU  IMAGE 

PROCEDURE 

CREATE  STACK 

PROCEDURE 

MM_ AD VANCE 

PROCEDURE 

mm’read  EVENTCOUNT 

PROCEDURE 

G  AST  LOCK 

WORD 

PREEMPT_RET 

LABEL 
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0000 


0  0  AO 
00A2 


3SECTI0N  TC_DATA 
INTERNAL 

APT  RECORD 

[  LOCK 

RUNNING_LIST 
R  EAD Y_LIST 
BLOCKED_LIST 
FILL_3 
VP 

FILL 

AP 

] 


WORD 

RUN_ARRAY 

RDY_ARRAY 

AP_PTR 

LONG 

VP_DATA 

ARR  AY[ 4  WORD] 

AP  DATA 


! THESE  VARIABLES  ARE  USED  DURING  TC 
INITIALIZATION  TO  SPECIFY  AVAILABLE 
ENTRIES  IN  THE  APT,  AND  ARE  INITIAL¬ 
IZED  BY  TC_INIT  IN  THIS  IMPLEMENTATION 
NEXT_VP  WORD 
APT  ENTRY  WORD 


0000 


0000 


0000 


$ SECT ION  TC  LOCAL 


SABS  0 

•NOTE:  USED  AS  OVERLAY  ONLY! 
ARG_LIST  RECORD 

[REG  ARRAY£  13  WORD] 


IC  WORD 

CPU_ID  WORD 

S  AC  1  LONG 

PH1 1  WORD 

USR_STK  WORD 

KER_STK  WORD 

KST 1  LONG 


3 


SABS  0 

INOTE:  USED  AS  STACK  FRAME  FOR 
STORAGE  OF  TEMPORARY  VARIABLES 
FOR  CREATE_PROCESS. 1 
CREATE  "RECORD 
[ARG_PTR  WORD 

DBR^NUM  WORD 

LIMITS  WORD 

SEG_ADDR  ADDRESS 
N_S_?  WORD 

1 


SABS  0 

HA  NDLE_VAL  RECORD 
[HIGH  LONG 
LOW  WORD 

3 


•THE  FOLLOWING  DECLARATION  IS  UTILIZED 
AS  A  STACK  FRAME  FOR  STORAGE  OF 
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0000 


0000 


TEMPORARY  VARIABLES  UTILIZED  BY 


TC_ADVANCE  AND 

TC_AWAIT 

SABS  0 

TEMP  RECORD 

[  HANDLE_PTR 

WORD 

EVENT_NR 

WORD 

EVENTUAL 

LONG 

ID  VP- 

WORD 

CPU  NUM 

WORD 

HAN  DLE_H IGH 

LONG 

HANDLE  LOW 

WORD 

] 

SSECTION  TC_KST_DCL 
! NOTE:  KST  DECLARATION  IS  USED  HERE 
TO  SUPPORT  KST  INITIALIZATION  FOR 
THIS  DEMONSTRATION  ONLY.  THIS 
DECLARATION  AND  INITIALIZATION 
SHOULD  EXIST  AT  THE  SEGMENT  MANAGER 
LEVEL  AND  THUS  SHOULD  BE  REMOVED 
UPON  IMPLEMENTATION  OF  SYSTEM 
INITIALIZATION. ! 

SABS  0 

KST  AR  R AY[  NR_KST  KST_REC] 
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0000 

0000 

0002 

0004 

0006 

0008 

000A 

OOOC 

OOOE 

0C10 

0012 

0014 

00  16 

0018 

001  A 

001C 

00  IE 

0020 

0022 

0024 

0026 

0028 

002A 

002C 

002E 

0030 

0032 

0034 

0036 

0038 


3 SECT ION  TC_INT_PROC 

TC_GETWORK  PROCEDURE 

«  ***************************** 

*  PROVIDES  GENERAL  MANAGE-  * 

*  M ENT  OF  USER  PROCESSES  BY  * 

*  EFFECTING  PROCESS  SCHEDU-  * 

*  LING  ON  VIRTUAL  PROCESSORS* 
***************************** 


*  PARAMETERS:  * 

*  R 1 :  CURRENT  VP  ID  * 

*  R3:  LOGICAL  CPU  t  * 

***************************** 

*  LOCAL  VARIABLES:  * 

*  R2:  NEXT  READY  PROCESS  * 

*  R4:  AP  PTR  * 


v****************************! 

ENTRY 

!  FIND  FIRST  READY  PROCESS  ! 

6132  LD  R2  ,  APT  .  READ Y_LIST  (R3) 

0006' 

GET  READY  AP: 

DO  “‘WHILE  NOT  (END  OF  LIST  OR  READY)! 
0B02  CP  R2,  #  NIL 

FFFF 

5E0E  IF  EQ  ! NO  READY  PROCESS!  THEN 

0010' 

5E08  EXIT  FROM  G  ET_RE AD  Y_ AP 

0026' 

FI 

4D2 1  CP  APT.  AP.  STATE  (R2)  ,  #READY 

002A' 

0001 

5E0E  IF  EQ  ! PROCESS  READY!  THEN 

00 1  E' 

5E08  EXIT  FROM  GET_READ Y_AP 

0026* 

FI 

!  GET  NEXT  AP  FROM  LIST  ! 

6124  LD  R4,  APT. AP. NEXT  AP  (R2) 

0020' 

A 1 42  LD  R2 ,  R4 

E8EF  OD 

0B02  CP  R2,#NIL 

FFFF 

5E0E  IF  EQ  !  IF  NO  PROCESSES  READY  !  THEN 

003C* 

!  LOAD  IDLE  PROCESS  ! 

4D15  LD  APT.  RUNNING_LIST  (R1)  ,  #IDLE_PROC 

0002' 

DDDD 

5F00  CALL  IDLE 

0000* 

5E08  ELSE 
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003  A 

0052' 

!  LOAD  FIRST  READY  AP  ! 

003C 

003E 

6F12 

0002' 

LD 

APT. RUNNING_LIST { R 1 )  ,  R2 

0040 

0042 

0044 

4D25 

002A' 

0000 

LD 

APT.  AP .  STATE  (R2)  ,  tRUNNING 

0046 

0048 

6F21 

00  2  E' 

LD 

APT.  AP.  V P_ID  (R2)  ,  R1 

004A 

004C 

6121 

0022* 

LD 

SI  ,  APT.  AP.  DBR  (R2) 

004E 

0050 

5F00 

0000* 

CALL 

FI 

SWAP_VDBR  !  (R  1 :  DBR)  ! 

0052 

9E08 

RET 

0054 

END  TC_ 

GETWORK 
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0054  VIRTUAL_PREEMPT_H ANDLER  PROCEDURE 

j *************************** 

*  LOADS  FIRST  READY  AP  * 

*  IN  RESPONSE  TO  PREEMPT  * 

*  INTERRUPT  * 

**************************** 


ENTRY 

!**  CALL  WAIT_LOCK  (APT-. LOCK)  **! 

!**  RETURNS  WHEN  PROCESS  HAS  LOCKED  APT  **! 


0054 

7604 

LDA 

R4,  APT. LOCK 

0056 

0000' 

0058 

5F00 

CALL 

K_LOCK 

005A 

0000* 

!  GET 

R UHN ING_VP  ID  ! 

005C 

5F00 

CALL 

RUNNING_VP  IRETURNS: 

005E 

0000* 

HI: VP_ID 

R3: CPU  t! 

!  GET 

AP  ! 

0060 

6112 

LD 

R2,  APT.RUNNING_LIST  (R1) 

0062 

0002* 

!  IF 

NOT  AN  IDLE  PROCESS,  SET  IT 

0064 

0B02 

CP 

R2,  #IDLE_PROC 

0066 

DDDD 

0068 

5E06 

IF  NE 

!  NOT  IDLE  !  THEN 

006A 

0072* 

006C 

4D25 

LD 

APT. AP . STATE (R2) ,  #READY 

006E 

002A ' 

0070 

0001 

FI 

!  LOAD  FIRST  READY  PROCESS  ! 

0072 

5F00 

CALL 

TC_GETWORK  !R1:VP_ID 

0074 

0000* 

R3:CPU  # ! 

!  NOTE: 

THIS  IS  THE  INITIAL  POINT 

EXECUTION  FOR  USER  PROCESSES.! 

VIRT_PREEMPT  RETURN: 

! **  CALL  UNLOCK  (APT-.  LOCK)  **! 

!**  RETURNS  WHEN  PROCESS  HAS  UNLOCKED  APT  ** 
!**  AND  ADVANCED  ON  THIS  EVENT  **! 


0076 

0078 

7604 

0000' 

LDA 

R4 ,  APT. LOCK 

007A 

007C 

5F00 

0000* 

CALL 

K_[JN  LOC  K 

007E  5E08 
0080  0000* 


!  PERFORM  A  VIRTUAL  INTERRUPT  RETURN  ! 
•NOTE:  THIS  JUMP  EFFECTS  A  VIRTUAL 
IRET  INSTRUCTION.! 

JP  PREEMPT  RET 


264 


0082 


END  VIRTUAL  PREEMPT 


HANDLER 


265 


GLOBAL 

SSECTION  TC_GLB_PROC 

0000  TC_INIT  PROCEDUHE 

i  ***************************** 

*  INITIALIZES  APT  HEADER  * 

*  AND  VIRTUAL  INT  VECTOR  * 

****** ************* ********** 

*  PARAMETERS:  * 

*  R1 :  CPU_ID  * 

*  R2:  N R_V  P  * 

***  ************************** i 


0000 

4D05 

LD 

0002 

00A0 ' 

0004 

0000 

0006 

4D05 

LD 

0  0  08 

00A2 ' 

OOOA 

0000 

OOOC 

4D05 

LD 

00  OE 

OOOA' 

0010 

FFFF 

0012 

4D08 

CLR 

0014 

0000' 

ENTRY 

!  NOTE:  THE  NEXT  FOUR  VALUES  ARE 
ONLY  TO  BE  INITIALIZED  ONCE.  J 
NEXT_VP ,  #0 


LD  APT_ENTR Y,  #0 


00  16 

2104 

LD 

0018 

0000 

DO 

001  A 

0304 

CP 

001C 

0004 

IF 

00  IE 

5E0E 

t: 

0020 

0026* 

0022 

5E08 

0024 

0036' 

FI 

J 

0026 

4D45 

LD 

0028 

0006' 

002A 

FFFF 

« 

LD  APT. BLOCKED_LIST,  #NIL 


CLR  APT. LOCK 

j  *****************************  ********** 

NOTE:  THE  FOLLOWING  CODE  IS  INCLUDED 
ONLY  FOR  SIMULATION  OF  A  MULTIPROCESSOR 
ENVIRONMENT.  THIS  IS  TO  INSURE  THAT  THE 
READY  LIST  (S )  AND  VP  DATA  OF  THE  SIMULATED 
CPU(S)  ARE  PROPERLY  INITIALIZED.  IN  AN 
ACTUAL  MULTIPROCESSOR  ENVIRONMENT,  THIS 
BLOCK  OF  CODE  SHOULD  BE  REMOVED. 

***************************************** j 

R4,  #0 


R4,  #NR_C?U*2 


INITIALIZE  READY_LISTS  AS  EMPTY  l 
APT . READY_LIST (R4)  ,  MIL 


INITIALLY  MARK  ALL  LOGICAL  CPU'S 
AS  HAVING  1  VP.  THIS  IS  NECESSARY 
TO  INSURE  TC_AD VANCE  WILL  FUNCTION 
PROPERLY,  AS~IT  EXPECTS  EVERY  CPU 
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TO  HAVE  AT  LEAST  1  VP.  J 


002C 

4D4  5 

LD  APT. VP. NR_VP (R4)  ,  #1 

002E 

0010* 

0030 

0001 

0032 

A94  1 

INC  R4,  #2 

0034 

E8F2 

!  END 

OD 

MULTIPROCESSOR  SIMULATION  CODE. 

*************************************** 

0036 

6F12 

LD 

APT.VP.NR_VP(R1) ,  R2 

0038 

0010' 

0  03A 

6103 

LD 

R3 ,  NEXT_VP 

003C 

00  AO ' 

003E 

6F13 

LD 

APT. VP. FIRST (R1) ,  R3 

0040 

0014* 

!  RECOMPUTE  NEXT_VP  VALUE  FOR  TC 

initialization"^  next  logical 

CPU. 

i 

0042 

A125 

LD 

R5,  R2 

0044 

1904 

MULT 

RR4,  #2 

0046 

0002 

0048 

8153 

ADD 

R3,  R5 

004  A 

6F03 

LD 

NE  XT_VP ,  R3 

004C 

00  AO ' 

1  INITIALIZE  RUNNING  LIST  i 

004E 

6113 

LD 

R3  ,  APT.  VP.PIRST(RI) 

0050 

0014* 

DO 

0052 

0B02 

CP 

R2 ,  #0 

0054 

0000 

0056 

5E0E 

IF  EQ  THEN  EXIT  FI 

0058 

005E* 

005A 

5E08 

0  0  5C 

006A' 

005E 

4D35 

LD 

APT.  RUNNING_LIST  (R3|  ,  #IDLE_PROC 

0060 

0002' 

0062 

DDDD 

0064 

A931 

INC 

R  3 ,  *2 

0066 

AB20 

DEC 

R2,  #1 

0068 

E8F4 

OD 

006A 

4D15 

LD 

APT.READY_LIST(R1) ,  #NIL 

006C 

0006* 

006E 

FFFF 

0070 

2101 

LD 

R1  ,  #0 

0072 

0000 

!  ENTRY  ADDRESS  I 

0074 

7602 

LD  A 

R2 ,  VIRTUAL_PREEMPT_HAN  DLER 

0076 

0054* 

0078 

5F00 

CALL 

CREATE_INT_VEC 

007A 

0000* 

!R1: VIRTUAL  INTERRUPT  # 

R2: INTERRUPT  HANDLER  ADDRESS! 

007C 

9E08 

RET 

007E 

END  TC_I NIT 
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007E 


CREATE_PROCSSS  PROCEDORE 
************************** 

*  CREATES  USER  PROCESS  * 

*  DATABASES  AND  APT  * 

*  ENTRIES  * 

a***** ********  *********** 

*  PARAMETERS:  * 

*  R 1 4 :  ARGUMENT  PTR  * 

************************* • 


007E 

030F 

0080 

000  A 

0082 

6FFE 

0084 

0000 

0086 

7604 

0088 

0000* 

00  8  A 

5FOO 

008C 

0000* 

008E 

5F00 

0090 

0000* 

0092 

6101 

0094 

00A2' 

0096 

2102 

0098 

0020 

009  A 

8112 

009C 

6F02 

009E 

00A2 ' 

00A0 

4D15 

00A2 

0020* 

00A4 

FFFF 

00A6 

6F10 

0CA8 

0022' 

00  A  A 

54E2 

00  AC 

00  1 E 

00  AE 

5D12 

00B0 

0024* 

00B2 

61E2 

ENTRY 

! NOTE:  THIS  PROCEDURE  IS  A  STUB  TO  ALLOW 
PROCESS  INITIALIZATION  FOB  THIS 
DEMONSTRATION. J 

!  ESTABLISH  STACK  FRAME  FOR  LOCAL 
VARIABLES.  I 

SUB  R15,  iSIZEOF  CREATE 

!  STORE  INPUT  ARGUMENT  POINTER  ! 

LD  CREATE.  ARG_PTR  (R15)  ,  R14 

!  LOCK  APT  ! 

LD  A  R4,  APT. LOCK 

CALL  K_LOCK 

J  RETURNS  WHEN  APT  IS  LOCKED  ! 

!  CREATE  MMU  ENTRY  FOR  PROCESS  .' 

CALL  ALLOCATE_MMU  ! RETURNS: 

RO:  DBR  #! 

1  GET  NEXT  AVAILABLE  ENTRY  IN  APT  ! 

LD  HI,  APT_ENTRY 

!  COMPUTE  APT  OFFSET  ! 

LD  R2,  #SI ZEOF  AP_TABLE 

ADD  R2r  HI 

!  SAVE  NEXT  AVAILABLE  APT  ENTRY  ! 

LD  APT_ENTRY,  R2 

!  CREATE  APT  ENTRY  FOR  PROCESS  J 
LD  APT.  AP.  NEXT_AP  (R1)  ,  #NIL 


LD  APT.  AP.  DBR  (HI)  ,  RO 

!  GET  PROCESS  CLASS  J 

LDL  RR2,  ARG_LIST.  SAC1  (R14) 

LDL  APT.  AP.  SAC  (R  1)  ,  RR2 

!  GET  PROCESS  PRIORITY  • 

LD  R2,  ARG_LIST.PR1 1  (R14) 
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00B4 

0022 

0  0B6 

6F12 

LD 

APT. AP.PRI  (R 1 )  ,  R2 

00B8 

0028* 

!  GET 

LOGICAL  CPU  #  ! 

OOBA 

6 1E2 

LD 

R2,  ARG_LIST. C PU_ID  (R  1  4) 

OOBC 

00  1C 

OOBE 

6F12 

LD 

APT.  AP.  AFFINITY(RI)  ,  R2 

OOCO 

002C' 

.'THREAD  IN  LIST  AND  MAKE  READY ! 

00C2 

7623 

LD  A 

S3  ,  APT  .READY_LIST  (R2) 

0  0C4 

0006  1 

00C6 

7604 

LD  A 

R4,  APT. AP. NEXT_AP 

00C8 

00  20  1 

OOCA 

7605 

LD  A 

R5,  APT. AP.PRI 

OOCC 

0028* 

OOCE 

7606 

LDA 

R6  ,  APT. AP. STATE 

OODO 

00  2A 1 

00D2 

2107 

LD 

R7,  #RE ADY 

00D4 

0001 

0  0D6 

AD  2 1 

EX 

HI,  R2 

!  SAVE  DBR  #  I 

00D8 

6FF0 

LD 

CREATE.  DBR_NUM  (R15)  ,  RO 

OODA 

0002 

00  DC 

5F00 

CALL 

LIST_IN  SERT 

OODE 

0000* 

!  R2:  OBJ  ID 

R3:  LIST  HEAD  PTR 

R4:  NEXT  OBJ  PTR 

R5;  PRIORITY  PTR 

R6:  STATE  PTR 

R7 :  STATE! 

I  UNLOCK  APT  ! 

OOEO 

7604 

LDA 

R4,  APT. LOCK 

0  0E2 

0000* 

00E4 

5F00 

CALL 

K_UNLOCK 

00E6 

0000* 

'CREATE  USER  STACK' 

'  RESTORE  ARGUMENT  POINTER  ! 

00E8 

6 1 FE 

LD 

R  1 4  ,  CREATE.  ARG_PTfi(R15) 

0  OEA 

0000 

0  0  EC 

61E3 

LD 

R  3 ,  ARG_LI ST . USR_STK (R14) 

0  OEE 

0024 

J  SAVE  LIMITS  ! 

0  OFO 

6FF3 

LD 

CREATE. LIMITS  (R15)  ,  R3 

0  0F2 

0004 

00F4 

5F00 

CALL 

MM_ALLOCATE  !R3:  *  OF  BLOCKS 

00F6 

0000* 

RETURNS; 

R2:  START  ADDR! 

'COMPUTE  6  SAVE  NSP! 

00F8 

A128 

LD 

33  ,  R2 

!  ESTABLISH  INITIAL  SP  VALUE 

FOR 

USER  STACK.  ! 

OOFA 

0108 

ADD 

38,  #STK_OFFSET 

269 


00FC 

OOFF 

OOFE 

6FF8 

LD 

CREATE. N_S_P  (R 15 )  ,  R8 

0100 

0008 

!  RESTORE  LIMITS  ! 

0102 

61F4 

LD 

R4 ,  CREATE. LIMITS  (R15) 

0  104 

0004 

0106 

AB40 

DEC 

R4  ! SEG  LIMITS! 

!  RESTORE  DBR  ! 

0108 

61F0 

LD 

RO,  CREATE.  DBR_NUM  (R1  5) 

0  10A 

0002 

010C 

2101 

LD 

R1,  #US  ER_ST  ACK 

0  10E 

0003 

0110 

2103 

LD 

R3,  #WRITE  ! ATTRIBUTE! 

0  112 

0000 

0114 

5F00 

CALL 

UPDATE_MMU_IMAGE 

0116 

0000* 

! RO:  DBR  # 

R 1 :  SEGMENT  # 

R2:  SEG  ADDRESS 

R3:  SEG  ATTRIBUTES 

R4 :  SEG  LIMITS! 

! CREATE  KERNEL  STACK! 

!  RESTORE  ARGUMENT  POINTER  ! 

0118 

6 1 FE 

LD 

R14,  CREATE. ARG_PTR(R15) 

0  1  1 A 

0000 

01  1C 

61E3 

LD 

R3  ,  ARG_LIST.KER_STK  (R14) 

01  IE 

0026 

0120 

5F00 

CALL 

MM_ALLOCATE  !R3:  »  OF  BLOCKS 

0122 

0000* 

RETURNS 

R2:  START  ADDR! 

’MAKE 

M  MU  ENTRY! 

!  RESTORE  DBR  *  ! 

0124 

6 1 FO 

LD 

RO  ,  CREATE.  DBR_NUM  (R15) 

0126 

0002 

0  128 

2101 

LD 

R1,  #KERNEL_STACK 

0 1  2  A 

0001 

012C 

A 1 34 

LD 

R4r  R3 

012E 

AB40 

DEC 

R4 

0130 

2103 

LD 

R3,  # WRITE 

0132 

0000 

!  SAVE  START  ADDRESS  ! 

0134 

6FF2 

LD 

CREATE.  SEG_ADDR(R15)  ,  R2 

0  136 

0006 

0138 

5F00 

CALL 

UPDATE_MMU_IMAGE 

0  1  3  A 

0000* 

!R0:  DER  # 

R 1 :  SEGMENT  # 

R2:  SEG  ADDRESS 

R3:  SEG  ATTRIBUTES 

R4:  SEG  LIMITS! 

! ESTABLISH  ARGUMENTS! 

!  RESTORE  ARGUMENT  POINTER  ! 

013C 

6  1  FE 

LD 

R  1 4,  CREATE.  AEG_PTR(R15) 
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0  13E 

0000 

!  RESTORE  STACK  ADDRESS  ! 

0140 

6  IF  1 

LD 

R1,  CREATE. SEG_ADDR(R15) 

0142 

0006 

0  1  44 

2103 

LD 

R3,  #USER_FCW 

0146 

1800 

0148 

61E4 

LD 

R4,  A  RG_  LI  ST. IC(R14) 

0  14A 

00  1 A 

!  RESTORE  INITIAL  NSP  ! 

0  14C 

61F5 

LD 

R5 ,  CREATE.N_S_P  (R15) 

014E 

0008 

0150 

7606 

LD  A 

R6,  VIRT_PREEMPT_RETURN 

0  152 

0076* 

0154 

030F 

SUB 

R 1 5,  #8 

0156 

0008 

0158 

1CF9 

LDM 

3R15,  R  3,  #4 

015A 

0303 

!  LOAD  ARGUMENT  POINTER  FOR 

CREATE  STACK  CALL  ! 

015C 

A1F0 

LD 

R  0 ,  R15 

015E 

93P1 

PUSH 

dR15,  R  1 

0160 

A 1 E 1 

LD 

HI,  R 14 

!  LOAD  INITIAL  REGISTER  VALUES  TO 

BE 

PASSED  TO  USER  PROCESS  AS 

INITIAL  PARAMETERS.  ! 

0  162 

5C 1 1 

LDM 

R2,  ARG_LIST.REG  (R1)  ,  #13 

0164 

020C 

0  166 

0000 

0168 

97F1 

POP 

R1,  a)R  1  5 

0  16A 

5F00 

CALL 

CREATE_STACK 

016C 

0000* 

! RO:  ARGUMENT  PTR 

R 1 :  TOP  OF  STACK 

R2-R14;  INITIAL 

REG  STATES! 

!  NOTE 

:  THE  ABOVE  INITIAL  REG  STATES 

REPRESENT  THE  INITIAL  PARAMETERS 

(VIZ 

. ,  EEGISTER  CONTENTS)  THAT  A 

USER 

PROCESS  HILL  RECEIVE  UPON 

INITIAL  EXECUTION.  ! 

016E 

01  OF 

ADD 

R15,  #8  .'OVERLAY  PARAMETERS! 

0170 

0003 

!  ALLOCATE  KST  ! 

0  172 

2103 

LD 

R3,  #K3T_LIMIT 

0  174 

0001 

0176 

5F00 

CALL 

MM_ALLOCATE  !R3:#  OF  BLOCKS 

0178 

0000* 

RETURNS 

R2:  START  ADDR  ! 

!  RESTORE  DBR  ! 

0  1 7  A 

6 1 FO 

LD 

RO,  CREATE.  DBR_NUM  (R15) 

017C 

0002 

•  SAVE  KST  ADDRESS  ! 

OWE 

6FF2 

LD 

CREATE. SEG_ADDR(R15) ,  R2 
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0180 

0006 

!  M  AKE 

M  MU 

ENTRY  FOR  KST  SEG! 

0182 
0  184 

2101 

0002 

LD 

HI, 

#KS  T_S  EG 

0186 

0188 

2103 

0000 

LD 

R3, 

#WRITE  1  ATTRIBUTE! 

018A 
0  18C 

2104 

0000 

LD 

H4, 

#KST_LIMIT-  1 

018E 

0190 

5FOO 

0000* 

CALL 

U  PDATE_MKU_IMAGE 

0192 
0  194 

0196 

0198 


61F2 

0006 

5F00 
0  1 A  0  * 


019A  010F 
019C  000 A 
019E  9E08 
0  1  AO 


JRO:  DBS  # 

HI:  SEGMENT  * 

R2:  SEG  ADDEESS 
R3:  SEG  ATTRIBUTES 
R4 :  SEG  LIMITS! 

!  RESTORE  KST  ADDEESS  ! 

LD  R2  ,  CREATE.  S  EG_ADDR  (R 1  5) 

!  CREATE  INITIAL  KST  STUB  ! 
CALL  CREATE_KST  !E2:KST  ADDR! 

!  REMOVE  TEMPORARY  VARIABLE 
STACK  FRAME.  ! 

ADD  R 1 5,  tSIZEOF  CREATE 

RET 

END  CREATE  PROCESS 


272 


0  1  AO  CRE ATE_KST  PROCEDORE 

j  ********1 **************** 

*  CREATES  KST  STUB  FOR  * 

*  PROCESS  MANAGEMENT  * 

*  DEMO.  INSERTS  ROOT  * 

*  ENTRY  IN  KST.  NOT  * 

*  INTENDED  TO  BE  FINAL  * 

*  PRODUCT.  * 

************************ 

*  PARAMETERS:  * 

*  R2:  KST  ADDRESS  * 

************************  t 

ENTRY 

’NOTE:  THIS  PROCEDURE  IS  A  STUB  USED 
FOR  INITIALIZATION  IN  THIS  IMPLEMENTATION 
ONLY.  THE  ACTUAL  INITIALIZATION  CODE 
FOR  THE  KST  HILL  RESIDE  AT  THE  SEGMENT 
MANAGER  LEVEL  ONCE  IMPLEMENTATION  OF 
SYSTEM  INITIALIZATION  IS  EFFECTED.  ! 


!  CREATE  ROOT  ENTRY  IN  KST  ! 


0  1A0 

1406 

LDL 

RR6,  #-1  ! ROO T  HANDLE 

01  A2 

FFF? 

0  1A4 

FFFF 

01A6 

5D26 

LDL 

KST. MM_HANDLE(R2) ,  RR6 

0  1A8 

0000 

•SET 

ROOT  ENTRY  #  IN  G_AST  ! 

0  1  AA 

4D25 

LD 

KST.  MM_HANDLE[  2]  (R2)  , 

01  AC 

0004 

0  1  AE 

0000 

!  SET 

ROOT  CLASSIFICATION  ! 

0  1  BO 

1406 

LDL 

RR6,  #SYSTEM_LOW 

0  1B2 

0000 

01B4 

0000 

0  136 

5D26 

LDL 

KST. CLASS (R2) ,  RR6 

01B8 

000A 

•SET 

MENTOR  SEG  #! 

01  BA 

4C25 

LD  B 

KST.  M_S EG_NO  (R2)  ,  #0 

0  1BC 

000E 

0  1  BE 

0000 

'.INITIALIZE  FREE  KST  ENTRIES 

FOR 

DEMO.  NOT  FULL  KST! 

01CG 

2101 

LD 

HI,  #10 

01C2 

000  A 

DO 

01C4 

0B01 

CP 

R  1  ,  #0 

01C6 

0000 

0  1C8 

5E0E 

IF  E 

:Q  THEN  EXIT  FI 

0  1CA 

01  DO* 

01CC 

5E08 

0  1 CE 

0 1  DE* 

0  1 D  0 

0102 

ADD 

H2,  #SIZEOF  KST.REC 

01D2 

0010 

273 


0  1D4 
01D6 
01D8 

4C25 

OOOE 

FFFP 

LDB 

KST.M_SEG_NO  (R2)  ,  *XFF 

0  1  DA 

AB  10 

DEC 

R  1 

01  DC 

E8F3 

OD 

0  1  DE 

9E08 

RET 

0  1  E0 

END  CREATE_KST 
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0 1 EO  TC_ADVANCE  PROCEDURE 

i  ******************************* ¥ 

*  EVENTCOUNT  IS  ADVANCED  BY  * 

*  INVOCATION  OF  MM  ADVANCE.  * 

*  PROCESSES  THAT  ARE  AWAITING  * 

*  THIS  EVENT  OCCURRENCE  ARE  * 

*  REMOVED  FROM  THE  BLOCKED  LIST* 

*  AND  MADE  READY.  THE  READY  * 

*  LISTS  ARE  THEN  CHECKED  TO  * 

*  INSURE  PROPER  SHEDULING  IS  * 

*  EFFECTED.  IF  NECESSARY  VIR-  * 

*  TUAL  PREEMPTS  ARE  SENT  TO  ALL* 

*  THOSE  VP'S  BOUND  TO  LOWER  * 

*  PRIORITY  PROCESSES.  * 

************** ****************** 

*  PARAMETERS:  * 

*  R1:  HANDLE  POINTER  * 

*  R2:  INSTANCE  (EVENT  #)  * 

******************************** 

*  RETURNS:  * 

*  RO:  SUCCESS  CODE  * 

********************************* 


ENTRY 

1  ESTABLISH  TEMPORARY  VARIABLE 
STACK  FRAME.  ! 


0 1  EO 

030F 

SUB 

R 1 5 ,  tSIZEOF  TEMP 

01E2 

0012 

!  SAVE 

INPUT  ARGUMENTS  ! 

01E4 

6FF1 

LD 

T  EMP  .  H  ANDLE_PT  R  (R 1 5) 

01E6 

0000 

01E8 

6FP2 

LD 

TEMP  .  EVENT_NR  (R15)  , 

0 1  EA 

0002 

!  LOCK 

;  APT  I 

01  EC 

7604 

LD  A 

R4  ,  APT. LOCK 

0  1  EE 

0000' 

0  1  FO 

5F00 

CALL 

K_LOCK 

0  1F2 

0000* 

*  RETURNS  WHEN  APT  IS  LOCKED  ! 

*  ANNOUNCE  EVENT  OCCURRENCE  BY 
INCREMENTING  EVENTCOUNT  IN  G_AST 

01F4  5F00  CALL  MM_ADVANCE  ! R1 :HANDLE  PTR 
0 1F6  0000* 

R2  INSTANCE 
RETURNS: 

R0:SUCC3SS  CODE 
RR  2: EVENTCOUNT I 


01F8  0B00  CP  RO,  #SUCCEEDED 
0 1  FA  0002 

0  1 FC  5E0E  IF  EQ  THEN 

0  1  FE  0372' 

I  SAVE  EVENTCOUNT  ! 

0200  5DF2  LDL  TEMP  .  EVENT_V  AL  (R  1  5)  ,  RR2 
0202  0004 
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!  RESTORE  INSTANCE  1 


0204 

6  1F0 

LD 

80,  TEMP.EVENT_NR  (R15) 

0206 

0002 

!  RESTORE  HANDLE  POINTER  ! 

0208 

6  IF  1 

LD 

HI,  TEMP.HANDLE_PTR(R15) 

0  20A 

0000 

!  SAVE 

HANDLE  ! 

020C 

5414 

LDL 

RR4 ,  HANDLE_VAL.  HIGH  (R1) 

0  20E 

0000 

0  210 

5DF4 

LDL 

TEMP.  HANDLE_HIGH  (R15)  ,  RR4 

0212 

OOOC 

0214 

6114 

LD 

R4,  HANDLE_V AL.  LOW  (R1) 

0216 

0004 

0218 

6FF4 

LD 

T EMP .  H  ANDLE_LO W  (R 1  5)  ,  R4 

021  A 

0010 

!  AWAKEN  ALL  PROCESSES  AWAITING 

THIS 

EVENT  OCCURRENCE  ! 

!  GET 

FIRST  BLOCKED  PROCESS  J 

0  2  1C 

6101 

LD 

R1,  APT . BLOC KED_LISI 

0  2  IE 

000  A ' 

0220 

7606 

LDA 

86,  APT . BLOCKED_LIST 

0222 

OOOA' 

W  AK  E_U  P 

• 

• 

DO 

!  DETERMINE  IF  AT  END  OF  BLOCKED 

0224 

0B01 

CP 

81,  #NIL 

0226 

FFFF 

IF  EQ 

!  NO  MORE  BLOCKED  PROCESSES 

0228 

5E0E 

THEN 

EXIT  FROM  W AK E_ U P 

022A 

0230* 

0  22C 

5S08 

022E 

02B4  • 

FI 

!  SAVE  NEXT  ITEM  IN  LIST  ! 

0230 

6117 

LD 

R7,  AFT.AP.  NEXT_AP(R1J 

0232 

0020' 

I  DETERMINE  IF  PROCESS  IS  ASSOCIA 

WITH  CURRENT  HANDLE  ! 

0234 

54F4 

LDL 

RR4  ,  TEMP.  KANDLE_HIGH  (R  15) 

0236 

OOOC 

0238 

5014 

CPL 

RR4 ,  APT.  AP.HANDLE(RI) 

0  23 A 

00  30 ' 

IF  EQ 

! HIGH  HANDLE  VALUE  MATCHES! 

0  23C 

5E0E 

THEN 

023E 

02  A2 ' 

0240 

6  1F4 

LD 

R4 ,  TEMP.  HANDL3_LOW  (R15) 

0242 

0010 

0244 

4B14 

CP 

84,  APT . AP. HANDLE[ 2  ]  (R 1 ) 

0246 

0034 ' 

IF  EQ 

!  HANDLE'S  MATCH  ! 

0248 

5E0E 

THEN 

!  CHECK  FOR  INSTANCE  MATCH 

0  2  4  A 

029C1 

0  24C 

6  1F0 

LD 

RO,  TEMP.  EVENT_NR  (R15) 

024E 

0002 
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0250 

4B10 

CP  RO 

,  APT 

.  AP. INSTANCE  (Rl) 

0252 

0036' 

IF  EQ  ! 

INSTANCE  MATCHES  ! 

0254 

5E0E 

THEN  ! DETERMINE  IF  THIS  IS  THE 

0256 

0296* 

OCCURRENCE  THE  PROCESS 
WAITING  FOR  ! 

0258 

54F2 

LDL 

RR2, 

TEMP  .  E  VENT_V  AL  (R  15) 

0  25  A 

0004 

0  25C 

5012 

CP  L 

RR2, 

APT. AP. VALUE  (Rl) 

0  25E 

0038' 

IF  GE 

! AWAITED  EVENT  HAS  OCCURRED 

0260 

5E0  1 

THEN 

!  AWAKEN  PROCESS  ! 

0262 

0290* 

!  REMOVE 

FROM  BLOCKED  LIST  ! 

0264 

2F67 

LD 

a)R6 

,  87 

!  SAVE  LOCAL  VARIABLES  ! 

0266 

91F6 

PUSHL  alfil  5 ,  RR6 

!  SET 

LIST 

THREADING  ARGUMENTS! 

0268 

6112 

LD 

82, 

APT.  AP.  AFFINITY  (Rl) 

026A 

002C* 

0  26C 

7623 

LDA 

R3r 

APT . R EADY_LIST  (R2) 

026E 

0006' 

0270 

7604 

LDA 

E4, 

APT . A  P . NEXT_AP 

0272 

0020' 

0274 

7605 

LDA 

H5, 

APT . AP . PRI 

0276 

00  28  • 

0278 

7606 

LDA 

R6, 

APT. AP. STATE 

027A 

002A* 

0  27C 

2107 

LD 

87# 

#READY 

027E 

0001 

0280 

A 1 1  2 

LD 

82, 

Rl 

0282 

5F00 

CALL 

LIST.INSERT 

0284 

0000* 

!R2 

:  OBJ 

ID 

0286 
0288 
0  2  8  A 
02  8C 
0  28E 
0290 


95F6 

21  OB 

ABCD 

5E08 

0292' 

8DB8 


0292  5E08 
0294  0293' 
0296  3DB8 


0298 
029  A 


5E08 

029E' 


83:  LIST  HEAD  PTH 
84:  NEXT  OBJ  PTE 
R5:  PRIORITY  PTR 
R6 :  STATE  PTR 
87:  STATE  VALUE  ! 

!  RESTORE  LOCAL  VARIABLES  I 
POPL  RR6  ,  a)R  15 
LD  811,  #R  EMCVED 

ELSE  ! PROCESS  STILL  BLOCKED! 

CLR  R 1 1 

FI  !  END  VALUE  CHECK  ! 

ELSE  ! PROCESS  STILL  BLOCKED! 

CLR  R11 

FI  !  END  INSTANCE  CHECK  ! 

ELSE  ! PROCESS  STILL  BLOCKED! 
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029C 

8DB8 

CL  R 

R  1 1 

FI  !  END  HANDLE  CHECK  ! 

029E 

5E08 

ELSE 

! PROCESS  STILL  BLOCKED! 

02  AO 

02  A4  • 

02A2 

8DB8 

CLR 

R 1  1 

FI  l  END  HIGH  HANDLE  CHECK  i 
!  RESET  AP  POINTER  REGISTERS  ! 

02A4 

OBOB 

CP 

R 1 1 ,  #REMOVED 

02A6 

ABCD 

IF  NE 

!  PROCESS  IS  STILL  BLOCKED  ! 

02A8 

5E06 

THEN 

02AA 

02B0 ' 

0  2  AC 

7616 

LD  A 

R6,  APT. AP. NEXT_AP (R1) 

02  AE 

0020  * 

FI 

02B0 

A 1 7  1 

LD 

R1,  R7 

02B2 

E8B8 

OD 

!  DETERMINE  IF  ANY  VIRTUAL  PREEMPT 

INTERRUPTS  ARE  REQUIRED  i 

02B4 

8D28 

CLR  R  2 

PREEMPT.. 

CHECK: 

DO 

02B6 

0B02 

CP 

R2,  # N R_C P U  *  2 

02B6 

0004 

0  2BA 

5E0E 

IF  EQ 

! ALL  READY  LISTS  CHECKED!  THE: 

02BC 

02C2 ' 

0  2BE 

5E08 

EXIT 

FROM  PREEMPT.CHECK 

02C0 

0366* 

FI 

!  CREATE  PREEMPT  VECTOR  FOR  VP'S  ! 

02C2 

8D18 

CLR 

R 1 

DO  ! FOR  R 1= 1  TO  NR  VP'S! 

02C4 

A910 

INC 

R1 

02C6 

4B2  1 

CP 

R1,  APT.  VP.NR_VP  (R2) 

02C8 

0010' 

IF  GT 

l  PREEMPT  VECTOR  COMPLETED  ! 

02CA 

5E02 

THEN 

EXIT 

0  2CC 

02D2' 

0  2CE 

5E08 

0  2D0 

02D8' 

FI 

02D2 

0DF9 

PUSH 

a)R15,  #TRUE 

02D4 

0001 

02D6 

E8F6 

OD 

!  #  TO 

PREEMPT  I 

02D8 

9D38 

CLR 

R  3 

02DA 

6124 

LD 

R4,  APT. VP.  NR_VP  (R2) 

02DC 

0010' 

!  #  OF 

VP'S  .' 

!  GET 

FIRST  READY  PROCESS  .' 

02DE 

6121 

LD 

R 1  r  APT. READY  LIST(fi2) 

0  220 

0006* 

CHECK_RDY  LIST: 
DO 
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02E2  0B01 
0  2  E4  FFFF 

02E6  5E0E 
02E8  02EE ' 
02EA  5E08 
02EC  0324' 

0 2EE  4D11 
02F0  002A ' 
02F2  0000 

0  2F4  5E0E 
02F6  030C' 
02F8  6115 
02FA  002E' 


!  SEE  IF  READY  LIST  IS  EMPTY  ! 
CP  R1,  #  NIL 

IF  EQ  ! LIST  IS  EMPTY! 

THEN  EXIT  FROM  CH  ECK_RDY  LIST 


FI 

C?  APT.  AP. STATE  (S  1)  ,  #RUNNI NG 


IF  EQ  '.PROCESS  IS  RUNNING! 
THEN  ! DON ' T  PREEMPT  IT! 

LD  R5,  APT.  AP  . VP_ID  (HI) 


02FC  4325 
0 2FE  0014' 
0300  74F6 
0302  0500 
0304  0D65 
0306  0000 
0308  5E08 
030A  030E' 
030C  A930 

0  30E  AB40 
0310  0B04 
0312  0000 

0314  5E0E 
0316  03  1C 
0318  5E08 
031A  0324* 


03  1C  6110 
0 3  IE  0020' 
0320  A 1 0 1 
0322  E8DF 

0324  6124 
0326  0010' 
0328  6121 
032A  0014* 


032C  97F0 

032E  0B00 
0330  0001 


!  COMPUTE  LOCATION  IN  PREEMPT  VECTOR 


SUB 

R5 ,  APT. VP. FIRST (R2) 

LDA 

R6,  R15(R5) 

LD 

986,  #  F  A  LS  E 

ELSE 

!  PREEMPT  IT  ! 

INC 

FI 

R3 

DEC 

R4 

CP 

R4 ,  #0 

IF  EQ 
THEN 

! ALL  VP'S  VERIFIED! 

EXIT  FROM  CHECK  RDY  LIST 


FI 

!  GET  NEXT  AP  IN  READY  LIST  ! 
LD  RO,  APT. AP.NEXT_AP (R1) 

LD  81,  RO 

OD  ! END  CHECK_RDY_LIST! 

!  SET  NECESSARY  PREEMPTS  ! 

LD  R4r  APT. VP. NR_VP (B2) 

LD  R 1  ,  APT.  VP.  FIRST  (H2) 

SEND_PREEMPT: 

DO 

POP  RO,  9R15 

!  CHECK  TEMPLATE  ! 

CP  RO,  #TRUE 

IF  EQ  ! C AN  BE  PREEMPTED! 


279 


0332 

5E0E 

THEN 

0334 

0350' 

0336 

0B03 

CP  R3,  #0 

0338 

0000 

IF  GT  !PREEMPTS  REQUIRED 

033& 

5E02 

THEN  .'PREEMPT  IT! 

033C 

0350' 

'SAVE  ARGUMENTS! 

033E 

93F1 

POSH  SR15,  R1 

0340 

9 1F2 

POSHL  SR15,  RR2 

0342 

93F4 

PUSH  SR15,  R4 

0344 

5F00 

CALL  SET_PREEMPT 

0346 

0000* 

!R1:  VP  ID! 

!  RESTORE  ARGUMENTS  ! 

0348 

97F4 

POP  R4 ,  SR  15 

0  34A 

95F2 

POPL  RR2,  SRI  5 

034C 

97F1 

POP  R 1 ,  SR  15 

034E 

AB30 

DEC  R3 

FI 

FI 

0350 

A911 

INC  El,  #2 

0352 

AB40 

DEC  R4 

0354 

0B04 

CP  R4,  #0 

0356 

0000 

IF  EQ  '.STACK  RESTORED! 

0358 

5E0E 

THEN 

035A 

0360' 

035C 

5E08 

EXIT 

035E 

0362* 

FI 

0360 

E8E5 

OD  ! END  SEND_PREEMPT! 

’  CHECK  NEXT  READY  LIST  ! 

0362 

A92 1 

INC  R2r  #2 

0364 

E8A8 

OD  ! END  PREEMPT_CHECK! 

!  UNLOCK  APT  ! 

0366 

7604 

LD A  H4,  APT. LOCK 

0368 

0000' 

036  A 

5F00 

CALL  K_UNLOCK 

036C 

0000* 

.'  RESTORE  SUCCESS  CODE  ! 

036E 

2100 

LD  RO,  #SUCCEEDED 

0370 

0002 

FI 

2  RESTORE  STACK  ! 

0372 

010F 

ADD  R15,  #SIZEOF  TEMP 

0374 

0012 

0376 

9E08 

RET 

0378 

END  TC_A DVANCE 
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0378  TC_A WA IT  PROCEDURE 

i ******** c ****** ****************** 

*  CHECKS  USER  SPECIFIED  VALUE  * 

*  AGAINST  CURRENT  EVENTCOUNT  * 

*  VALUE.  IF  USER  VALUE  IS  LESS  * 

*  THAN  OR  EQUAL  EVENTCOUNT  THEN* 

*  CONTROL  IS  RETURNED  TO  USER.  * 

*  ELSE  USER  IS  BLOCKED  UNTIL  * 

*  EVENT  OCCURRENCE.  * 

******************************** 

*  PARAMETERS:  * 

*  R1  :  HANDLE  POINTER  * 

*  R2 :  INSTANCE  (EVENT  #)  * 

*  RR4 :  SPECIFIED  VALUE  * 

******************************** 

*  RETURNS:  * 

*  RO:  SUCCESS  CODE  * 

*********************♦**********! 


0378  030F 
0 37A  0012 

037C  6FF 1 
037E  0000 
0380  6FF2 
0382  0002 
0384  5DF4 
0386  0004 

0388  7604 
038A  0000* 
038C  5F00 
0  38E  0000* 


0390  5F00 
0392  0000* 


0394  0B00 
0396  0002 
0398  5E0E 
03 9 A  0440* 


0 39C  54F6 
039E  0004 
03A0  9046 


ENTRY 

!  ESTABLISH  STACK  FRAME  FOR 
TEMPORARY  VARIABLES.  I 
SUB  R  1  5 ,  VSIZEOF  TEMP 

!  SAVE  INPUT  PARAMETERS  ! 

LD  TEMP.  HANDLE_PTR  (R15)  ,  R1 

LD  T EMP . EVENT_NR (R1 5) ,  R2 

LDL  TEMP.EVENT_.VAL  (R15)  ,  RR4 

!  LOCK  APT  ! 

LD  A  R4  ,  APT. LOCK 

CALL  K_LOCK 

!  RETURNS  WHEN  APT  IS  LOCKED  ! 

!  GET  CURRENT  EVENTCOUNT  ! 

CALL  MM_READ_EVENTCOUNT 

! R 1 : HANDLE  POINTER 
R 2:  INSTANCE 
RETURNS: 

RO : SUCCESS_CODE 
RR4:  EVENTCOUNT l 
CP  RO,  fSUCCEEDED 

IF  EQ  THEN 

!  DETERMINE  IF  REQUESTED  EVENT 
HAS  OCCURRED  ! 


LDL 

RR6, 

TEMP. EVENT_VAL(R15) 

CPL 

RR6, 

HR  4 
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IF  GT 

! EVENT  HAS  NOT  OCCURREDI 

0  3  A2 

5E02 

THEN 

! BLOCK  PROCESS! 

03A4 

0440* 

!  IDENTIFY  PROCESS  ! 

03A6 

5F00 

CALL 

RUNNI NG_ VP  IRETURNS: 

03A8 

0000* 

HI:  VP  ID 

R3 :CPU  #! 

*  SAVE  RETURN  VARIABLES  ! 

03  AA 

6FP 1 

LD 

TEMP.  ID_VP  (R  15)  ,  R 1 

0  3  AC 

0008 

03  AE 

6FF3 

LD 

TEMP.  CPU _NUM  (R15)  ,  R3 

03B0 

000A 

03B2 

61  18 

LD 

R8  ,  APT.  RUNNING_LIST  (R  1) 

03B4 

0002* 

!  RESTORE  REMAINING  ARGUMENTS  I 

0  3B6 

6 1F2 

LD 

R2  ,  TEMP  .EVENT_Nfi(R15) 

03B8 

0002 

03BA 

6 1  F 1 

LD 

R1 ,  TEMP. HAN DLE_PTR (R15) 

03BC 

0000 

!  SAVE  EVENT  DATA  ! 

0  3BE 

5414 

LDL 

RR4,  HANDLE_VAL. HIGH (R 1 ) 

G3C0 

0000 

03C2 

5D84 

LDL 

APT. AP. HANDLE (R8) ,  RR4 

0  3C4 

0030* 

03C6 

6114 

LD 

R4  ,  HANDI.E_VAL.LOH  (R1) 

0  3C8 

0004 

0  3CA 

6F84 

LD 

APT.  AP.HANDLEf  2]  (R8)  ,  R4 

03CC 

0034* 

0  3CE 

6F82 

LD 

APT.  AP. INSTANCE  (R8)  ,  R2 

03D0 

00  36' 

03D2 

54F6 

LDL 

RR6,  TEMP.  EVENT_VAL  (R15) 

0  3D4 

0004 

03D6 

5D86 

LDL 

APT. AP. VALUE  (R8)  ,  RR6 

03D8 

0038* 

2  REMOVE  PROCESS  PROM  READY  LIST 

0  3DA 

6131 

LD 

R1,  APT. AP. AFFINITY (R8) 

03  DC 

002C' 

0  3DE 

6112 

LD 

R2  ,  APT.  READ Y.LISI  (R1) 

03E0 

0006' 

!  SEE 

IF  PROCESS  IS  FIRST 

ENTRY  IN  READY  LIST  ! 

03E2 

8B62 

CP 

R2 ,  R8 

IF  EQ 

•INSERT  NEW  READY  LIST  HEAD 

03E4 

5E0E 

THEN 

0  3E6 

03F4 ' 

03E8 

6183 

LD 

R3 ,  APT. AP.NEXT_AP (£8) 

03  EA 

0020' 

0  3  EC 

6F13 

LD 

APT.READY_LIST  (R1)  ,  R3 

03EE 

0006* 

03F0 

5E08 

ELSE 

•DELETE  FROM  LIST  BODY! 

03F2 

040E ' 

DO 

0  3F4 

6123 

LD 

R3 ,  APT.AP. NEXT_AP (R2) 
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0  3F6 

0020* 

03F8 

8B83 

CP 

R3,  R8 

0  3F  A 

5E0E 

IF  EQ  ! FOUND  ITEM  IN  LIST! 

THEN 

0  3FC 

040  A* 

03FE 

0400 

6183 

0020' 

LD  R3,  APT.AP.NEXT_AP  (R8) 

0402 

0404 

6F23 

0020* 

LD  APT. AP. NEXT_AP (R2)  ,  R3 

0406 

5E08 

EXIT 

0408 

04  OE  • 

FI 

04  OA 

A132 

LD 

R2,  R3 

0  4  OC 

E8F3 

OD 

FI 

{THREAD  PROCESS  IN  BLOCKED  LIST! 

040E 

A182 

LD 

R2 ,  R8 

0410 

7603 

LDA 

R3,  APT. BLOCKED_LIST 

0412 

OOOA' 

04  14 

7604 

LDA 

R4 ,  APT. AP.NEXT_AP 

0416 

0020* 

04  18 

7605 

LDA 

R5 ,  APT.AP.PRI 

04  1A 

0028* 

04  1C 

7606 

LDA 

R6 ,  APT. AP. STATE 

04  IE 

002  A  • 

0420 

2107 

LD 

R7,  #  BLOCKED 

0422 

0002 

0424 

5F00 

CALL 

LIST_INSERT  !R2:OBJ  ID 

0426 

0000* 

R3 : LIST  HEAD  PTR 
R4 : NEXT  OBJ  PTR 
R5: PRIORITY  PTR 
R6 : STATE  PTR 

R7 : STATE  ! 

!  GET 

CURRENT  VP  ID  ! 

0428 

6  IF  1 

LD 

HI,  TEMP.ID_VP  (R15) 

04  2A 

0008 

042C 

61F3 

LD 

R3,  TEHP.CPU_NUM  (R15) 

042E 

OOOA 

!  SCHEDULE  FIRST  READY  PROCESS  ! 

0430 

5F00 

CALL 

TC_GETWORK  !R1:VP_ID 

0432 

0000' 

R3 : CPU  #! 

1  UNLOCK  APT  ! 

0  4  34 

7604 

LDA 

R4,  APT. LOCK 

0436 

0000* 

0438 

5F00 

CALL 

K_UNLOCK 

043A 

0000* 

!  RESTORE  SUCCESS  CODE  ! 

043C 

2100 

LD 

RO,  f SUCCEED  ED 

043E 

0002 

FI 

FI 

!  RESTORE  STACK  ! 
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B15,  #SIZ20F  TEMP 


0440 

010F 

ADD 

0442 

0012 

0444 

9E08 

BET 

0446 

END  TC 

AWAIT 


284 


0446  PRO  CESS_CLASS  PROCEDURE 

j  ************************$**v 

*  READS  SECURITY  ACCESS  * 

*  CLASS  OF  CURRENT  PROCESS  * 

*  IN  APT.  CALLED  BY  SEG  * 

*  MGR  AND  EVENT  MGR  * 

**************************** 

*  LOCAL  VARIABLES:  * 

*  HI:  VP  ID  * 

*  R5:  PROCESS  ID  * 

**************************** 

*  RETURNS:  * 

*  RR2:  PROCESS  SAC  * 

**************************** i 


ENTRY 


0446 

0448 

7604 

0000' 

LDA 

R4  r APT. LOCK 

044A 

044C 

5F00 

0000* 

CALL 

K_LOCK  !  R4  :-»APT  .  LOCK! 

044E 

0450 

5F00 

0000* 

CALL 

RUNNING_VP  IRETURNS: 

Hi:  VP_ID 
R3: CPU  # ! 

0452 

0454 

6115 

0002' 

LD 

R5  ,  APT . RUN  NING_LIST (R1 ) 

0456 

0458 

5452 

0024' 

LDL  RR2,  APT.  AP.SAC  (R5) 

!  UNLOCK  APT  ! 

045A 

045C 

7604 

0000' 

LDA 

R 4  ,  APT. LOCK 

045E 

0460 

5F00 

0000* 

CALL 

K_UNLOCK 

0462 

9E08 

RET 

0464 

END  PROCESS_CLASS 
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0464  GET_DB RENUMBER  PROCEDURE 

i * ** *** ** ****** *******  ****** ****** 

*  OBTAINS  DBR  NUMBER  FROM  APT  * 

*  FOR  THE  CURRENT  PROCESS.  * 

*  CALLED  BY  SEGMENT  MANAGER  * 

********************************* 


*  LOCAL  VARIABLES:  * 

*  R1:  VP  ID  * 

*  R5:  PROCESS  ID  * 

********************************* 

*  RETURNS:  * 

*  HI:  DBR  NUMBER  * 


********************************* ; 

ENTRY 

‘NOTE:  DBR  #  IS  ONLY  VALID  WHILE  PROCESS 
IS  LOADED.  THIS  IS  MO  PROBLEM  IN  SASS 


AS  ALL  PROCESSES  REMAIN  LOADED. 

IN 

A 

MORE 

GENERAL  CASE/  THE  DBE  # 

COULD 

ONLY 

BE  ASSUMED  CORRECT  WHILE  THE 

APT 

IS 

LOCKED 

0464 

7604 

LDA 

R4  rAPT. LOCK 

0466 

0000* 

0468 

5F00 

CALL 

K_LOCK  !R4:  -«APT.  LOCK! 

046  A 

0000* 

046C 

5?00 

CALL 

RUNNING_VP  ! RETURNS: 

046E 

0000* 

81: VP  ID 

R3: CPU  #! 

0470 

6115 

LD 

R5,APT. RUNNING_LIST (R 1) 

0472 

0002' 

0474 

6151 

LD 

R1 ,APT. AP. DBR ( R5) 

0476 

0022' 

i  UNLOCK  APT  I 

0478 

7604 

LDA 

R4  ,  APT. LOCK 

047A 

0000* 

0  4  7C 

5F00 

CALL 

K_UNLOCK 

047E 

0000* 

0480 

9E08 

RET 

0482 

END  GET 

_DBR_NUMBER 

END  TC 
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Appendix  C 

DISTRIBUTED  MEMORY  MANAGES  LISTINGS 


Z800Q ASM  2.02 

LOC  OBJ  CODE  STMT  SOURCE  STATEMENT 


SLISTON  $TTY 
DIS T_MM  MODULE 

CONSTANT 


CRE ATE_CODE 

=  50 

DELETE  CODE 

=  51 

ACT IV  ATE_COD  E 

=  52 

DEACTIV  ATE_CODE 

=  53 

SWAP_IN_CODE 

=  54 

SWAP_OUT_CODB 

=  55 

NR  CPU 

=  2 

nr!kst_entry 

=  54 

MAX_SEG_SIZE 

=  128 

MAX_DBR_NO 

=  4 

KST  _S  EG_NO 

=  2 

NR_OF_KSEGS 

=  10 

BLOCK_SIZE 

=  8 

MEM_AVAIL 

=  SFOO 

G_AST_LIMIT 

=  10 

INSTA  NCE1 

=  1 

INSTANC  E2 

=  2 

INVALID_INSTANCE 

=  95 

SUCCEEDED 

=  2 

TYPE 

H_ARB AY  ARRAY  [3 

COM_MSG  ARRAY  [16 

ADDRESS  »ORD 


AST_REC 

RECORD 

UNIQU  E_ID 

LONG 

3L0BAL_ADDR 

ADDRESS 

p  L  ASTE_NO 

WORD 

FLAG 

WORD 

P  AR_ASTE 

WORD 

NR_  ACTI  VE 

WORD 

NO  ACT_DEP 

BYTE 

SIZE1 

BYTE 

WORD  ] 
BYTE  ] 
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PG_TB  L 
ALIAS_TBL 
S  EQUENCER 
EVENT1 
EVENT  2 

] 

MM  VP  ID 


ADDRESS 

ADDRESS 

LONG 

LONG 

LONG 


WORD 


SEG_ARR AY  ARRAY  [ MAX_SEG_SIZE  BYTE] 


SSECTION  D_MM_DATA 
GLOBAL 


0000  MM_CPU_TBL  ARRAY  [ NR_CPU  MM_VP_ID] 

SSECTION  AVAIL_MEM 
INTERNAL 

!  NOTE:  MEM_POOL  IS  LOCATED  IN 
CPU  LOCAL~MEMORY.  ! 

0000  MEM_POOL  ARRAY  [ MEM_A VAIL  BYTE] 

GLOBAL 

!  NOTE:  NEXT_BLOCK  IS  USED  IN  THE  MM_ ALLOCATE 
STUB  AS  AN  OFFSET  POINTER  INTO  THE  BLOCK 
OF  ALLOCATABLE  MEMORY.  IT  IS  INITIALIZED 
IN  BOOTSTRAP  LOADER.  ! 

0  F00  NEXT_BLOCK  word 

SSECTION  MSG  FRAME_DCL 
INTERNAL 

•NOTE:  THESE  RECORDS  ARE  ''OVERLAYS''  OR  "FRAMES"  USED 
TO  DEFINE  MESSAGE  FORMATS.  NO  MEMORY  IS  ALLOCATED  ! 
SABS  0 


0000 

CREATE_MSG 

RECORD 

[ CR_CODE 
CE_MM._HANDLE 
CE_ENTRY_NO 

ceIfill 

CE_SIZE 

CE_CLASS 

WORD 

H_ARRA Y 

SH ORT_INTEGER 
BITE 

WORD 

LONG] 

0000 

SABS  0 
DELETE_MSG 

RECORD 

[ DE_CODE 
DE_MM_HANDLE 
DE  ENTRY  NO 
DE_FILL 

WORD 

H_ARRA Y 

SHORT  INTEGER 
ARRAYf  7  BYTE  ]] 

0000 

SABS  0 

ACTIVATE_MSG 

RECORD 

[  ACT_CODE 
A_DBR_NO 
A_MM_HANDLE 
A~ENTRY  NO 

A  SEGMENT  NO 

A  FILL 

WORD 

WORD 

H_ ARRAY 

SHORT  INTEGER 
SHORT~INTEGER 
LO  NG  ] 
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0000 

0000 

0000 

0000 

0000 

0000 


SABS  0 

DEACTIVATE  MSG 


SABS  0 
SWAP  IN  MSG 


SABS  0 

SWAP  OOT  MSG 


SABS  0 

HET  SOC  CODE 


SABS  0 

B  ACTIVATE  ARG 


RECORDf DEACT_CODE 

WORD 

D_DBR_NO 

WORD 

D_MM_HANDLE 

H_ ARRAY 

D_FILL 

ARRAYf  3 

RECORD 

[  S_IN_CODE 

WORD 

SI_MM  HANDLE 

H  ARRAY 

SI_DBR  NO 

WORD 

SI_ACCESS  AUTH  BYTE 

SI  FILL  1 

BYTE 

SI_FILL 

ARRAY[  2 

RECORD 

[ S_OUT_CODE 

WORD 

SO  DBR  NO 

WORD 

SO_MH_HANDLE 

H_ ARRAY 

SO  FILL 

ARR  AY[  3 

RECORD[SUC_CODE 

BYTE 

SC_FILL 

ARRAY[  1 

RECORD 

[  R_SUC  CODE 

BYTE 

R~FILL 

BYTE 

R_MM_HANDLE 

H_ARRAY 

R^CLASS 

LONG 

R_SIZE 

WORD 

R  FILL1 

WORD] 

SABS  0 

MM  HANDLE  RECORD 

f ID  LONG 

ENTRY  NO  WORD 

] 

EXTERNAL 


G_AST_LOCK 

WORD 

G_AST  ARRAY[G_ 

AST_LIMII  G_ASI_REC  ] 

K_LOCK 

PROCEDURE 

KJJNLOCK 

PROCEDURE 

GET_CPU_NO 

PROCEDURE 

SIGNAL 

PROCEDURE 

WAIT 

PROCEDURE 
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GLOBAL 

SSECTION  D  MM  PROC 


0000  M  M_C  HEAT  E_E  N  T  R  Y  PROCEDURE 

l  *  *41**  *  ********  *******  ******  ****** 

*  INTERFACE  BETWEEN  S EG  MGR  * 

*  (CREAT E_SEG  PROCEDURE)  AND  * 

*  M MG R  PROCESS  (CRE  ATE_ENTRY  * 

*  PROCEDURE) .  ARRANGES  AND  * 

*  PERFORMS  IPC.  * 

********************************* 

*  REGISTER  USE:  * 

*  PARAMETERS  * 

*  RO : SUCCESS_CODE  (RET)  * 

*  R1 :  HPTR  (INPUT)  * 

*  R2:ENTRY_NO  (INPUT)  * 

*  R3 : SIZE  7lNPUT)  ♦ 

*  RR4 : C  LASS  (INPUT)  * 

*  LOCAL  USE  * 

*  R6 : MM  HANDLE  ARRAY  ENTRY  * 

*  R8 :  -»COM_MSGBUF  * 

*  R1 3;-»COM  MSGBUF  * 


*********************************  I 

ENTRY 

•USE  STACK  FOR  MESSAGE! 


0000 

0002 

030F 

0010 

SUB 

R15, tSIZEOF 

COM_MSG 

0004 

A1FD 

LD 

B 13f  R15  ! 

-»COM_MSGBUF  ! 

! FILL  COM_MSG BUF  (LOAD  MESSAGE).  CREATE  MSG 
FRAME  IS  BASED  AT  ADDRESS  ZERO.  IT  IS 
OVERLAID  ONTO  COM  MSGBUF  FRAME  BY  INDEXING 
EACH  ENTRY  (I.E.  ADDING  TO  EACH  ENTRY)  THE 
BASE  ADDRESS  OF  COM  MSGBUF! 


0006  4DD5  LD 

0008  0000 
0 0 0 A  0032 
000C  3116  LD 

000E  0000 
0010  6PD6  LD 

0012  0002 
0014  3116  LD 

0016  0002 
0018  6FD6  LD 

00 1  A  0004 
001C  31 16  LD 

0  0 1 E  0004 
0020  6FD6  LD 

0022  0006 
0024  6FD2  LD 

0026  0008 
0028  5DD4  LD L 

0  02 A  000C 


CREATE_MSG  .  CR_CODE  (R13)  ,  #C3EATE_CODE 

S6  , R  1  (#0)  .'INDEX  TO  MM_HANDLE  ENTRY! 

CREATE_MSG.CE_MM_HANDLE[  0 ] (R13)  ,R6 
R6,R1  (#2) 

C  REATE_MSG. CE_MM_HANDLE[  1 ]  (R1 3)  ,R6 
R6,R1  (#4) 

CREATE_MSG.CE_MM_HANDLE[  2 ] (R 1 3)  ,R6 
CREATE_MSG.CE_ENTRY_NO (E13) ,R2 
CREATE_MSG.CE_CLASS(R13)  ,RR4 
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002C 

002E 

6FD3 

000  A 

LD 

CREATE_MSG.CE_SIZE  (R13)  ,R3 

0030 

AIDS 

LD 

R8  f R 13 

0032 

0034 

5F00 

018C' 

CALL  PERFORM_IPC  !R8:  -<COM_MSG BUF ! 

IRETRIEVE  SUCCESS_CODE  FROM  RETURNED  MESSAGE! 

0036 

8D08 

CLR 

RO 

0038 

003A 

60D8 

0000 

LDB 

RLO, RET_SUC_CODE . S  OC_CODE (R13) 

003C 

003E 

010F 

0010 

ADD 

S 1 5  r  #SI ZEOF  COM_MSG  ‘RESTORE  STACK  STATE! 

0040 

9E08 

RET 

0042 

END 

MM_CREATE_ENTRY 
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0042 


0042 

0044 

0046 


0048 
004  A 
004C 
004E 
0050 
0052 
0054 
0056 
0058 
005A 
005C 
005E 
0060 
0062 
0064 
0066 
0068 
006  A 
006C 
0  06E 

0070 
0072 
0074 
0076 
0078 
0  07  A 
00  7C 


MM_DELETE_ENTRY  PROCEDURE 

i ********************************* 

*  INTERFACE  BETWEEN  S EG  MGR  * 

*  ( DELET E_SEG  PROCEDURE)  AND  * 

*  MMGR  (DELETE_ENTRY  PROCEDURE).* 

*  ARRANGES  AND  PERFORMS  IPC.  * 

********************************* 


*  REGISTER  USE:  * 

*  PARAMETERS  * 

*  RO :  SUCCESS_CODE  (EE.T)  * 

*  R1 :  HPTR  (INPUT)  * 

*  R2:  ENTRY_NO  (INPUT)  * 

*  LOCAL  USE  * 

*  R6:MM_HANDLE  ARRAY  ENTRY  * 

*  R8 :  -»COM_MSGBUF  * 

*  R1  3 :  -»COM  MSGBUF  * 


********************************* i 


030F 
0010 
A  1FD 


ENTRY 

! USE  STACK  FOR  MESSAGE! 

SUB  R15,#SIZE0F  COM_MSG 

LD  R  13, R 15  !  -COM_MSGBUF  ! 

! FILL  COM_MSGBUF  (LOAD  MESSAGE).  DEL  ETE_MSG  FRAME 
IS  BASED  AT  ADDRESS  ZERO.  IT  IS  OVERLAID  ONTO 
COM_MSGBUF  FRAME  BY  INDEXING  EACH  ENTRY  (I.E.  ADD- 
ING~TO  EACH  ENTRY)  THE  BASE  ADDRESS  OF  COM  MSGBUF! 
DELETE_HSG.DE_C0DE(R13) , #DELETE_CODE 


R6  ,R 1  (#0)  ! IN DEX  TO  MM_HANDLE  ENTRY! 

DELETE_MSG.DE_MM_HANDLE( 0 ]  (R13) ,R6 
R6,R1  (#2) 

DELETE_MSG. DE_MM_HANDLE[  1  ]  (R 1 3)  ,R6 
R6,R  1  (#4) 

DELETE_MSG.DE_MM_HANDLE[  2]  (R13)  ,R6 
DELETE_MSG.DE_ENTEY_NO (R13) ,R2 
R8 , R 1 3 

PERFORM_IPC  !R8:  -*C0M_MSG  BUF ! 

[EVE  SUCCESS_CODE  FROM  RETURNED  MESSAGE! 

RO 

RLO, RET_SUC_CODE . SUC_CODE (R13) 

R 1 5, #SIZEOF  COd_MSG  ! RESTORE  STACK  STATE 


4DD5 

LD 

0000 

0033 

3116 

LD 

0000 

6FD6 

LD 

0002 

3116 

LD 

0002 

6FD6 

LD 

0004 

3116 

LD 

0004 

6FD6 

LD 

0006 

6FD2 

LD 

0008 

A1D8 

LD 

5F00 

CALL 

018C* 

iret: 

8D08 

CLR 

60D8 

LDB 

0000 

01  OF 

ADD 

0010 

9E08 

RET 

END 

MM_D 
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007C 


007C 

007E 

0080 

0082 


0084 
0086 
0088 
008A 
008C 
008E 
0090 
0092 
0094 
0096 
0098 
009  A 
009C 
009E 
0  0  AO 
00A2 
00A4 
OOA6 
00A8 


MM_ ACTIV  ATE  PROCEDUHE 

i  *************************,(1,1,****** 

*  INTERFACE  BETWEEN  SEG  MGR  * 

*  (MAKE_KNOWN  PROCEDURE)  AND  * 

*  tlMGR  (ACTIVATE  PROCEDURE)  .  * 

*  ARRANGES  AND  PERFORMS  IPC.  * 

******** ************************* 


*  REGISTER  USE:  * 

*  PARAMETERS  * 

*  R1  :DBR_NO(INPUT)  * 

*  R2:HPTR  (INPUT)  * 

*  R3:ENTRY_NO  * 

*  R4 :SEGMENT_NO  * 

*  R1 2; RET_HAN DLE  PTR  * 

*  LOCAL  USE  “  * 

*  R8 :  -*COM_MSGBUF  * 

*  R1 3  :-»COM_MSGBUF  * 

*  RETURNS:  * 

*  RO: SUCCESS  CODE  * 

*  RR2:CLASS  * 

*  R4 : SIZE  * 


*********************************  j 

ENTRY 

•USE  STACK  FOR  MESSAGE! 

030F  SUB  R 15, tSIZEOF  COM_MSG 

0010 

A1FD  LD  R  13,  R 15  !  -.COM  MSGBUF  ! 

!  SAVE  RETURN  HANDLE  POINTER  ! 

93FC  PUSH  a)  R 15 ,  R12 

•FILL  COM_MSGBUF  (LOAD  MESSAGE).  ACTIVAT E_MSG  FRAME 
IS  BASED  AT  ADDRESS  ZERO.  IT  IS  QVERLAID~ONTO 
COM_MSGBUF  FRAME  BY  INDEXING  EACH  ENTRY  (I.E.  ADD- 
ING_TO  EACH  ENTRY)  THE  BASE  ADDRESS  OF  COM  MSGBUF! 


4DD5 

0000 

0034 

LD 

A CTIVAT E_MSG . ACT_CODS ( R1 3)  , #ACTIVATE_CODE 

6FD1 

0002 

LD 

ACTI VAT E_MSG . A_DBR_NO (R13)  ,R1 

3126 

0000 

LD 

R6  ,R2  (#0) 

6FD6 

0004 

LD 

ACTIV  AT E_MSG .  A_MM_HAN DLE[  0  ]  (R  1  3)  ,R6 

3126 

0002 

LD 

R6  ,R2  (#2) 

6FD6 

0006 

LD 

ACTIVATE_MSG.i_MM_HANDLE[  1  ]  (R 1  3)  ,R6 

3126 

0004 

LD 

R6,R2  (#4) 

6FD6 

0008 

LD 

ACTIVATE_MSG.  A_MM_HANDLE[  2  ](R13)  ,R6 

6EDB 
000  A 

LDB 

ACTIVATE_MSG.  A_ENTRX_NO  (R13)  ,RL3 
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00  A  A  6EDC 
00AC  OOOB 
00 AE  A 1 D8 
OOBO  5F00 
00B2  0 18C' 

00B4  97FC 


LDB  ACTI V AT E_MSG. A_S EGMENT_NQ  (B13)  , RL4 

LD  R  8  ,  R  1 3 

CALL  PERFORM_IPC  ! (R8 :-*COM_MSGBUF! 

!  RESTORE  RETURN  HANDLE  POINTER  I 
POP  R12,  a)R  1 5 


00B6  54D6 
00B8  0002 
OOBA  5DC6 
0 0 BC  0000 
OOBE  61D6 
OOCO  0006 
00C2  6PC6 
00C4  0004 


!  UPDATE  MM_H ANDLE  ENTRY  ! 

LDL  R  R6,  R_ACTIVATE_ARG. R_MM_H ANDLE  (R13) 
LDL  M M_H ANDLE.  ID  (R  12)  ,  RR6 
LD  R6  ,R_ACTIV  ATE_ARG.  R_MM_HAN  DLE[  2](R13) 
LD  MM_HANDLE.  ENTRY_NO  (R12)  ,  R6 


00C6  8D08 
00C8  60D8 
OOCA  0000 
OOCC  54D2 
OOCE  0008 
OODO  61D4 
00D2  OOOC 
00D4  010F 
00D6  0010 
00D8  9E08 
OODA 


! RETRIEVE  OTHER  RETURN  ARGUMENTS ! 

CL  R  RO 

LDB  RLO,R_ACTIVATE_ARG.R_SUC_CODE (R13) 

LDL  RR2, R_ACTIVATE_ARG.R_CLASS  (R 1 3 ) 

LD  R«,R_ACTIVATE_ARG.R_SIZE  (R  13) 

ADD  R15,#SIZE0F  COH_HSG  i RESTORE  STACK  STATE! 
RET 

END  MM  ACTIVATE 
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OODA  MM_DEACTI VATE  PROCEDURE 

; ****:****4t4t*4^***4<4>4i4t4c4t*********** 

*  INTERFACE  BETWEEN  SEG  MGR  * 

*  (TERMINATE  PROCEDURE)  AND  * 

*  MMGR  (DEACTIVATE  PROCEDURE)  .  * 

*  ARRANGES  AND  PERFORMS  IPC.  * 

********* ****************** ****** 

*  REGISTER  USE:  * 

*  PARAMETERS  * 

*  RO:  SUCCESS  CODE  (RET)  * 

*  R1  :  DBR_NO  (INPUT)  * 

*  R2:  HPTR  (INPUT)  * 

*  LOCAL  USE  * 

*  R6:MM_HANDLE  ARRAY  ENTRY  * 

*  R8:  ->COM_MSGBUF  * 

*  R1  3  :-*COM_MS  G8UF  * 

**************************4141*****  t 


ENTRY 

(USE  STACK  FOR  MESSAGE! 

OODA  030F  SUB  R15,#SIZEOF  COM  MSG 
OODC  0010 

OODE  A1FD  LD  R13,R15  !  -.COM_MSGBUF  ! 


! FILL  COM_MSGBUF  (LOAD  MESSAGE).  DEACTIV ATE_MSG  FRAME 
IS  BASED  AT  ADDRESS  ZERO.  IT  IS  OVERLAID  ONTO 
COM_MSGBUF  FRAME  BY  INDEXING  EACH  ENTRY  (I.E.  ADD- 
I NG~TO  EACH  ENTRY)  THE  BASE  ADDRESS  OF  COM_MSGBUF! 


00E0 

4DD5 

LD 

DEACTIV  ATE_MSG . DEACT_CODE (R 1 3)  , 

00E2 

0000 

#DE  AC  II  VATE_CODE 

00E4 

0035 

00E6 

6FD1 

LD 

D  E  ACTIV  ATE_MSG .  D_DBR_NO  (R 1  3)  ,R1 

00E8 

0002 

0  OE  A 

3126 

LD 

R6 ,R2  (#0)  ! IN DEX  TO  MM_H A NDLE  ENTRY! 

00  EC 

0000 

OOEE 

6FD6 

LD 

DEACTIV  ATE_MSG . D_MM_HANDLE£  0 ] (R13)  ,R6 

00F0 

0004 

00F2 

3126 

LD 

R6 ,R2 (#2) 

00F4 

0002 

00F6 

6FD6 

LD 

DEACTIV ATE_MSG.D_MM_HANDLE[ 1 ]  (R 1 3)  ,R6 

00F8 

0006 

OOFA 

3126 

LD 

R6  ,H2  (#4) 

OOFC 

0004 

OOFE 

6FD6 

LD 

DEACTIVATE_MSG.D_MM_HANDLE£ 2 ] (R13)  ,  R6 

0100 

0008 

0102 

AIDS 

LD 

R8  ,R  1 3 

0  104 

5F00 

CALL 

?ERFORM_IPC  !R8:  -»COM_MSG  BUF  ! 

0106 

018C' 

! RETRIEVE  SUCCESS_CODE  FROM  RETURNED  MESSAGE! 

0108 

8D08 

CLR 

RO 

0  1  0  A 

60D8 

LDB 

RLOrRET_SUC_CODE.SUC_CODE (R13) 
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010C  0000 
0 1 0E  010F 
0110  0010 
0112  9E08 
0114  END 


ADD  R 15, tSIZEOF  COM_MSG  ! RESTORE  STACK  STATE 
RET 

MM  DEACTIVATE 
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01  14 


MM_SWAP_IN  PROCEDURE 

j  ********************************* 

*  INTERFACE  BETWEEN  SEG  MGR  (SM_* 

*  SWAP_IN  PROCEDURE)  AND  MMGR 

*  (SWAP_IN  PROCEDURE)  .  ARRANGES  * 

*  AND  PERFORMS  IPC.  * 

******** ************************* 


0114 
0  1 16 

030F 

0010 

SUB 

01  18 

A 1 FD 

LD 

REGISTER  USE:  * 

PARAMETERS  * 

RO: SUCCESS  CODE (RET)  * 

R1  :DBR_NO  (INPUT)  * 

R2:  HPTR  (INPUT)  * 

R3:  ACCESS  (INPUT)  * 

LOCAL  USE  * 

R6:MM_HANDLE  ARRAY  ENTRY  * 

R8 :  ->COM_MSGBUF  * 

R1  3  :->COM_MSGBUF  * 

********************************* i 

ENTRY 

!USE  STACK  FOR  MESSAGE! 

R15,#SIZEOF  COM_MSG 


R  1  3,  R 1 5  !  -.COM_MSGBUF  i 


FILL  COM_MSGBUF  (LOAD  MESSAGE) .  SWAP_IN_MSG  FRAME 
IS  BASED  AT  ADDRESS  ZERO.  IT  IS  OVERLAID  ONTO 
COM_MSGBUF  FRAME  BY  INDEXING  EACH  ENTRY  (I. E.  ADD 
ING  TO  EACH  ENTRY)  THE  BASE  ADDRESS  OF  COM_MSGBUF 


01  1 A 

4DD5 

LD 

SWAP_IN_MSG 

0  1  1C 

0000 

01  IE 

0036 

0120 

3126 

LD 

R6,R2(#0) 

0122 

0000 

0  124 

6FD6 

LD 

SWAP_IN_MSG 

0126 

0002 

0128 

3126 

LD 

R6  ,R2  (#  2) 

012A 

0002 

012C 

6FD6 

LD 

SWAP_IN_MSG 

012E 

0004 

0130 

3126 

LD 

R6,R2(#4) 

0132 

0004 

0134 

6FD6 

LD 

S  W  AP_IN_MSG 

0136 

0006 

0138 

6FD1 

LD 

SWAP_IN_MSG 

0  1 3  A 

0008 

0  13C 

6EDB 

LDB 

SWAP_IN_MSG 

013E 

000A 

0140 

A 1 D8 

LD 

R  8 ,R  13 

0142 

5F00 

CALL 

P  ERFORM_IPC 

0144 

018C’ 

’RETRIEVE  SUCCESS 

0146 

8D08 

CLR 

RO 

0  148 

60D8 

LDB 

RLO,RET_SUC 
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0  14A 
0  14C 
014E 
0150 
0152 


0000 

010F  ADD  R15,#SIZEOF  COM_MSG  1RESTORE  STACK  STATE! 

0010 

9E08  RET 

END  MM  SWAP  IN 
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MM_SWAP_OUT  PROCEDURE 

; **************************** ***** 

*  INTERFACE  BETWEEN  SEG  MGR  (SM_* 

*  SWAP_OUT  PROCEDURE)  AND  MMGR 

*  (SWAP_OUT  PROCEDURE) .  ARRANGES* 

*  AND  PERFORMS  IPC.  * 

********************************* 

*  REGISTER  USE:  * 

*  PARAMETERS  * 

*  RO:  SUCCESS  CODE  (RET)  * 

*  R1  :DBR_NO  (INPUT)  * 

*  R2:  HPTR  (INPUT)  * 

*  LOCAL  USE  * 

*  R6 : MM_H ANDLE  ARRAY  ENTRY  * 

*  R8:  -»COM_MSGBUF  * 

*  R13:-COM_MSGBUF  * 

*********************************  » 

ENTRY 

!USE  STACK  FOR  MESSAGE! 

SUB  R  1 5, #SIZEOF  COM_MSG 

LD  R  1 3  ,  R  1  5  !  -»COM_MSGBUF  ! 

! FILL  COM_MSGBUF  (LOAD  MESSAGE).  SWAP_OUT_MSG  FRAME 
IS  BASED  AT  ADDRESS  ZERO.  IT  IS  0 V ERLAI D~ON TO 
COM_MSGBUF  FRAME  BY  INDEXING  EACH  ENTRY  (I.E.  ADD¬ 
ING  TO  EACH  ENTRY)  THE  BASE  ADDRESS  OF  COM_MSGBUF! 


0158 

4DD5 

LD 

SWAP_OUT_MSG.5_OUT_CODS(R13) ,  #SWA  ?_OUT_COD  S 

015A 

0000 

015C 

0037 

0  15E 

3126 

LD 

R6,R2(#0)  !  INDEX  TO  MM_HA  NDLE  ENTRY! 

0160 

0000 

0162 

6FD6 

LD 

SWAP_OUT_MSG.SO_MM_HANDLE[  0] (R13)  ,R6 

0164 

0004 

0  166 

3126 

LD 

R6,R2  (#2) 

0168 

0002 

0  1 6  A 

6FD6 

LD 

SWAP_OUT_MSG.SO_MM_HANDLE[  1  ]  (R  13)  ,R6 

016C 

0006 

0  16E 

3126 

LD 

R6,R2  (#4) 

0170 

0004 

0172 

6FD6 

LD 

SWAP_OUT_MSG.SO_MM_HANDLS[  2]  (R13) , R6 

0174 

0008 

0  176 

6FD1 

LD 

S WAP_OUT_MSG . SO_DBR_NO (R13)  ,R1 

0178 

0002 

0  1 7  A 

A1D8 

LD 

R8  ,R  1  3 

017C 

5F00 

CALL 

PERFORM_IPC  !R8:  -»COM_MSG  BUF! 

0  17E 

0  1 8C  • 

! R BTRIEVE  SUCCESS_CODE  FROM  RETURNED  MESSAGE! 

0180 

8D08 

CL  R 

RO 

0  182 

60D8 

LDB 

RLO, RET_SUC_CO DE . SUC_CODE (R13) 

0184 

0000 

0186 

01  OF 

ADD 

R  15, #SIZEOF  COM_MSG  ! RESTORE  STACK  STATE! 

0188 

0010 

0152 


0152  030F 
0154  0010 
0156  A1FD 
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0  18A 
0  18C 


9E08  RET 

END  MM_SWAP_OUT 
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018C  PER  FORM_IPC  PROCEDORE 

l  **************  *********************** 

*  SERVICE  ROUTINE  TO  ARRANGE  AND  * 

*  PERFORM  IPC  WITH  THE  MEM  MGR  PROC  * 

*******************************  ****** 

*  REGISTER  USE:  * 

*  PARAMETERS  * 

*  R8:  -.COM_MSG  (INPUT)  * 

*  LOCAL  USE  * 

*  R1,R2:  WORK  REGS  * 

*  R4  :  ->G_AST_LOCK  * 

*  R13:  -.COM  MSGBUF  * 


*************************************  I 


ENTRY 

018C 

93FD 

PUSH 

a)R  15  ,  R1  3  1  -*COM_MSGBUF ! 

0  18E 

5F00 

CALL 

GET_CPU_NO  ! RET-R1 :CPU_NO! 

0190 

0000* 

0192 

A 1 1 2 

LD 

R2,R1 

0194 

6121 

LD 

HI, MM_CPU_TBL (R2)  !MM_VP_ID! 

0196 

0000* 

0198 

7604 

LDA 

R4,G_AST_LOCK 

019A 

0000* 

019C 

5F00 

CALL 

K_LOCK 

019E 

0000* 

0  1A0 

5F00 

CALL 

SIGNAL  ! R  1 :  MM_VP_ID ,  R8:  -«COM_  MSGBUF 

01A2 

0000* 

0  1  A4 

97FD 

POP 

R 1 3, 3R 1 5 

01A6 

A 1  D8 

LD 

R  8 ,  R  1 3  !-«COM_MSGBUF! 

01A8 

93FD 

PUSH 

SR15,R13 

0  1  AA 

5F00 

CALL 

WAIT  ! R8:-COM_MSGBUFI 

01  AC 

0000* 

0  1  AE 

7604 

LDA 

R4 ,G_AST_LOCK 

0  1B0 

0000* 

01B2 

5F00 

CALL 

K_UNLOCK 

01B4 

0000* 

01B6 

97FD 

POP 

R  1  3 ,  a>R  1  5 

0  1B8 

9E08 

RET 

01  BA 

END 

i  PERFORM_IPC 
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0  1  BA  MM_ ALLOCATE  PROCEDURE 

»  ************************** 

*  ALLOCATES  BLOCKS  OF  CPU* 

*  LOCAL  MEMORY.  EACH  * 

*  BLOCK  CONTAINS  256  * 

*  BYTES  OF  MEMORY.  * 

************************** 


*  PARAMETERS:  * 

*  R3:  #  OF  BLOCKS  * 

*  RETURNS:  * 

*  R2 :  STARTING  ADDR  * 

*  LOCAL:  * 

*  R4 :  BLOCK  POINTER  * 


*********************  *****1 


ENTRY 

!  NOTE:  THIS  PROCEDURE  IS  ONLY  A  STUB 
OF  THE  ORIGINALLY  DESIGNED  MEMORY 
ALLOCATING  MECHANISM.  IT  IS  USED 
BY  THE  PROCESS  MANAGEMENT  DEMONSTRATION 
TO  ALLOCATE  CPU  LOCAL  MEMORY  FOR  ALL 
MEMORY  ALLOCATION  REQUIREMENTS.  IN  AN 
ACTUAL  SASS  ENVIRONMENT,  THIS  WOULD 
BE  BETTER  SERVED  TO  HAVE  SEPARATE 
ALLOCATION  PROCEDURES  FOR  KERNEL  AND 
SUPERVISOR  NEEDS.  (E.G.,  KERNE L_ALLOCATE 
AND  S  U  PER  VIS  OR_  ALLOC  ATE)  .  ! 

!  COMPUTE  SIZE  OF  MEMORY  REQUESTED  ! 

0 1  BA  B33 1  SLL  R3,  #BLOCK_SIZE 
0 1 BC  0008 


01C8  6F04 
0 1 CA  OFOQ  * 
CMCC  9E08 
0  ICE 


!  COMPUTE  OFFSET  OF  MEMORY  THAT  IS 
TO  BE  ALLOCATED  ! 


0  1  BE 
01C0 

6104 
0F00  • 

LD 

84, 

NEXT_BLOCK 

01C2 
0  1C4 

7642 

0000* 

LDA 

82, 

MEM_POOL(R4) 

0  1C6 

8134 

ADD 

84, 

R3  !  UPDATE 

OFFSET! 

!  UPDATE  OFFSET  IN  SECTION  OF  AVAILABLE 
MEMORY  TO  INDICATE  THAT  CURRENTLY 
REQUESTED  MEMORY  IS  NOW  ALLOCATED  ! 

LD  NEXT_BLOCK,  R4  ISAVE  OFFSET! 

RET 

END  MM  ALLOCATE 
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0  1CE  MM_TICKET  PROCEDURE 

; ***************************** 


*  RETURNS  CURRENT  VALUE  OF  * 

*  SEGMENT  SEQUENCER  AND  * 

*  INCREMENTS  SEQUENCER  VALUE* 

*  FOR  NEXT  TICKET  OPERATION  * 
***************************** 

*  PARAMETERS:  * 

*  R1:  SEG  HANDLE  PTR  * 

*  RETURNS:  * 

*  RR4 :  TICKET  VALUE  * 

*  LOCAL  VARIABLES:  * 

*  RR6 :  SEQUENCER  VALUE  * 

*  R8 :  G  AST  ENTRY  #  * 


***************************** i 

ENTRY 

!  SAVE  HANDLE  PTR  ! 


0  1 CE 

93F1 

PUSH 

a)R  1 5 ,  R1 

!  LOCK  G  AST  J 

0  1  DO 

7604 

LDA 

R4  ,  G_AST_LOCK 

0  1  D2 

0000* 

0  1D4 

5F00 

CALL 

K_LOCK 

0  1D6 

0000* 

!  RESTORE  HANDLE  PTR  ! 

01D8 

97F1 

POP 

R  1  ,  a)R1  5 

!  GET 

G  AST  ENTRY  *  ! 

0  IDA 

6118 

LD 

R8,  MM_HANDLE. ENTRY_NO (R 

01  DC 

0004 

!  GET 

TICKET  VALUE  ! 

0  1 DE 

5486 

LDL 

R R6  ,  G_AST.  SEQUENCER  (R8) 

0  1E0 

00  14* 

I  SET 

RETURN  REGISTER  VALUE  ! 

01E2 

9464 

LDL 

RR4,  RR6 

1ADVANCE  SEQUENCER  FOR  NEXT 

TICKET  OPERATION! 

0  1E4 

1606 

ADDL 

RR6 ,  #1 

0  1E6 

0000 

01E8 

0001 

!  SAVE 

:  NEW  SEQUENCER  VALUE  IN 

0  1  EA 

5D86 

LDL 

G^AST.  SEQUENCER  (R8)  ,  RR6 

01  EC 

0014* 

!  UNLOCK  G_AST  ! 

!  SAVE 

!  RETURN  VALUES  ! 

0  1  EE 

91F4 

PUSHL 

3R15,  RR4 

0  1 FO 

7604 

LDA 

R4 ,  G_AST_LOCK 

0  1F2 

0000* 

01F4 

5F00 

CALL 

K_UNLOC  K 

01F6 

0000* 

!  RETRIEVE  RETURN  VALUES  ! 

0  1F8 

95F4 

PO  PL 

RR4,  3R15 

0  1  FA 

9E08 

RET 

0  1 FC 

END  MM 

TICKET 
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01  PC 


M M_ RE A D_ EVENTCOUNT  PROCEDURE 

; ********  ******  *********  ******** 

*  READS  CURRENT  VALUE  OF  THE  * 

*  EVENTCOUNT  SPECIFIED  BY  THE  * 

*  USER.  * 

******************************* 

*  PARAMETERS:  * 

*  R1 :  SEG  HANDLE  PTR  * 

*  R2 :  INSTANCE  (EVENT  #)  * 

**************  ***************** 

*  RETURNS:  * 

*  RR4:  EVENTCOUNT  VALUE  * 

******************************* 

*  LOCAL  VARIABLES:  * 

*  RR6:  SEQUENCER  VALUE  * 

*  R8:  G_AST  ENTRY  #  * 

******************************* t 


ENTRY 

!  SAVE  INPUT  PARAMETERS 


0  1  FC 

93F 1 

PUSH 

9R15,  R 1 

0  1  FE 

93F2 

PUSH 

§R  15  ,  R2 

!  LOCK 

:  G_AST  ! 

0200 

7604 

LDA 

R4 ,  G_AST_LOCK 

0202 

0000* 

0204 

5F00 

CALL 

K_LOCK 

0206 

0000* 

I  RESTORE  INPUT  PARAMETERS  J 

0208 

97F2 

POP 

R2 ,  5>R15 

0  20  A 

97  FI 

POP 

R  1  ,  a)  R  1  5 

!  GET 

G  AST  ENTRY  #  i 

0  20C 

6118 

LD 

38,  MM_HANDLE.  ENTRY_NO  (R 

02  OE 

0004 

!  READ 

i  EVENTCOUNT  ! 

!  CHECK  WHICH  EVENT  #  ! 

IF  R2 

0210 

0B02 

CASE 

#INSTA  NCE 1  THEN 

0212 

0001 

0214 

5E0E 

0216 

0224' 

0218 

5484 

LDL 

RR4 ,  G_AST . E  VENT  1 (R8) 

0  2  1 A 

0018* 

02  1C 

2100 

LD 

RO,  fSUCCEEDED 

0  2 1 E 

0002 

0220 

5E08 

CASE 

#INSTANCE2  THEN 

0222 

023C' 

0224 

0B02 

0226 

0002 

0228 

5E0E 

022A 

0238' 

022C 

5464 

LDL 

RR4 ,  G_AST.EVENT2(R8) 

022E 

001C* 

0230 

2100 

LD 

RO,  tSUCCEEDED 

0232 

0002 

304 


! INVALID  INPUT! 


0234  5E08 
0236  023C * 
0238  2100 
023A  005F 


023C  91F4 

0 23E  7604 
0240  0000* 
0242  5F00 
0244  0000* 

0246  95F4 
0248  9E08 
024A 


ELSE 

LD  R0,  #INV  ALID_I NSTANCE 
FI 

!  NOTE:  NO  VALUE  IS  RETURNED  IF 
USER  SPECIFIED  INVALID  EVENT  # 
!  SAVE  RETURN  VALUES  ! 

PUSHL  a»R  15 ,  RR4 
!  UNLOCK  G_AS T  ! 

LD A  R4,  G_AST_LOCK 

CALL  K_UNLOCK 

!  RESTORE  RETURN  VALUES  ! 

POPL  RR4  r  a)R  1 5 
RET 

END  MM  READ  EVENTCOUNT 
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0  24 A  MM_ AD  V  ANCE  PROCEDURE 

«  *****  *  ********  *********  ******** * *** 

*  DETERMINES  G_AST  OFFSET  FROM  * 

*  SEGMENT  HANDLE  AND  INCREMENTS  * 

*  THE  INSTANCE  (EVENT  #)  SPECIFIED  * 

*  BY  THE  CALLER.  THIS  IN  EFFECT  * 

*  ANNOUNCES  THE  OCCURRENCE  OF  THE  * 

*  EVENT.  THE  NEW  VALUE  OF  THE  * 

*  EVENTCOUNT  IS  RETURNED  TO  THE  * 

*  CALLER.  * 

*********************************** 

*  PARAMETERS:  * 

*  R1 :  HANDLE  POINTER  * 

*  R2:  INSTANCE  (EVENT  #)  * 

*********************************** 

*  RETURNS:  * 

*  RR2:  NEW  EVENTCOUNT  VALUE  * 

***********************************  l 

ENTRY 


!  SAVE 

1  INPUT  PARAMETERS  ! 

024A 

93F1 

POSH 

3  R  15  ,  R  1 

024C 

93F2 

POSH 

3R15,  R2 

!  LOCK 

G__AST  ! 

024E 

7604 

LD  A 

R4,  G_AST_LOCK 

0250 

0000* 

0252 

5F00 

CALL 

K_LOCK 

0254 

0000* 

!  RESTORE  INPUT  PARAMETERS  I 

0256 

97F2 

POP 

R2  ,  3R15 

0258 

97F  1 

POP 

R  1  ,  3R15 

!  GET 

G_AST  OFFSET  ! 

0  25  A 

6114 

LD 

R4 ,  MM_HANDLE. ENTRY_NO (R 

0  25C 

0004 

I  DETERMINE  INSTANCE  J 

IF  R2 

025E 

0B02 

CASE 

#INSTANCE 1  THEN 

0260 

0001 

0262 

5E0E 

0264 

027C* 

0266 

5442 

LDL 

RR2,  G_AST. EVENT  1 (R4) 

0268 

0018* 

0  26  A 

1602 

ADDL 

RR2,  #1 

026C 

0000 

0  26E 

0001 

!  SAVE  NEW  EVENTCOUNT  ! 

0270 

5D42 

LDL 

G_AST .EVENT1 (R4) ,  RR2 

0272 

0018* 

0274 

2100 

LD 

RO,  #SUCCEEDED 

0276 

0002 

0278 

5E08 

CASE 

SINSTANCE2  THEN 

0  27  A 

029E' 

027C 

0B02 

027E 

0002 
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0280 

5E0E 

0282 

029A' 

0284 

5442 

LDL 

RR2,  G_AST.EVENT2 (R4) 

0286 

001C* 

0288 

1602 

ADDL 

RR2,  #1 

028A 

0000 

0  28C 

0001 

!  SAVE  NEW  EVENTCOUNT  ! 

0  28E 

5D42 

LDL 

G_AST.EVENT2  (R4)  ,  RR2 

0290 

00  1C* 

0292 

2100 

LD 

RO,  #SUCCEEDED 

0294 

0002 

0296 

5E08 

ELSE 

’INVALID  INPUT! 

0298 

029E' 

029A 

2100 

LD 

RO,  #INV  ALID_IN STANCE 

0  29C 

005F 

FI 

!  NOTE 

:  AN  INVALID  INSTANCE  VALUE 

WILL 

NOT  AFFECT  EVENT  DATA  ! 

!  UNLOCK  G  AST  ! 

0  29E 

7604 

LD  A 

R4,  G_AST_LOCK 

0  2  AO 

0000* 

02A2 

5F00 

CALL 

K_ UN LOCK 

02A4 

0000* 

02A6 

9E08 

BET 

02A8 

END  MM_ 

ADVANCE 

END  DIST 
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Appendix  D 

GATE  KEEPER  LISTINGS 


Z8  000  ASM  2.02 

LOC  OBJ  CODE  STMT  SOURCE  STATEMENT 


KERNEL_GATE_KEEPER  MODULE 

SLISTON  $TTY 


CONSTANT 

ADVANCE  CALL 
AWAIT.CALL 
CREATE_SEG_CALL 
DSLETE_SEG_CALL 

make_known“call 

READ~CALL 

SM_SWAP_IN_CALL 

SM_SWAP_OUT_CALL 

TERMINATE  CALL 

TICKET_CALL 

WHITEHALL 

WRITE LN_CALL 

CRLF  CALL 

WRITE 

WRITELN 

CRLF 

MONITOR 

R EG IS TER _B LOCK 
TRAP_CODE_0?FSET 
INVALID  KERNEL  ENTRY 


1 

2 

3 

4 

5 

6 

7 

8 

9 

10 


13 

X0FC8  ! PRINT  CHAR! 

%0FCQ  IPRINT  MSG! 

S0FD4  iCAR  RET/LINE  FEED! 

SA902 

32 

36 

%BAD 


GLOBAL 


3ATE_KEEPER_ENTRY 

LABEL 

[TERNAL 

ADVANCE 

PROCEDURE 

AWAIT 

PROCEDURE 

CREATE_SEG 

PROCEDURE 

DELETE  SEG 

PROCEDURE 

MAKE_KNOWN 

PROCEDURE 

READ~ 

PROCEDURE 

SM_SWAP_IN 

PROCEDURE 

SM_SWAP  OUT 

PROCEDURE 

TERMINATE 

PROCEDURE 

TICKET 

PROCEDURE 

KERNEL.EXIT 

LABEL 

- 

308  - 

0 


INTERNAL 

$SSCTIO N  KERNEL_GATE_PROC 
0000  GATE_KEEPER_MAIN  PROCEDURE 


ENTRY 


GATE_KEEPER_ENTRY: 

!  SAVE  REGISTERS  I 


0000 

030F 

SUB  R  1 5,  #REGISTER_BLOCK 

0002 

0020 

0004 

1CF9 

LDM  SR  15  ,  R1,  #16 

0006 

010F 

!  SAVE  NSP  ! 

0008 

93F2 

PUSH  SR15,  R2 

000A 

7D27 

LDCTL  R  2 ,  NSP 

!  RESTORE  INPUT  REGISTERS  ! 

oooc 

2DF2 

EX  R  2 ,  SR  1  5 

!  SAVE  REGISTER  2  ! 

000E 

93F2 

PUSH  SR  15  ,  R 2 

1  GET  SYSTEM  TRAP  CODE  ! 

00  10 

31F2 

LD  R 2 ,  R15  (#TRAP_CODE_OFFSET) 

0012 

0024 

•  REMOVE  SYSTEM  CALL  IDENTIFIER 
SYSTEM  TRAP  INSTRUCTION  ! 

0014 

8C28 

CL  RB  RH2 

•  NOTE:  THIS  LEAVES  THE  USER  VISIBLE 
EXTENDED  INSTRUCTION  NUMBER  IN  R2  ! 

!  DECODE  AND  EXECUTE  EXTENDED  INSTRUCTION 
IF  R2 

!  NOTE:  THE  INITIAL  VALUE  FOR  REGISTER  2 


0016  0B02 
0018  0001 
00  1 A  5E0S 
001C  0028' 
001 E  97F2 
0020  5FOO 
0022  0000* 
0024  5E08 
0026  010C' 
0028  0B02 
002A  0002 
002C  5E0E 
002E  003A ' 
0030  97F2 
0032  5F00 
0034  0000* 
0036  5E08 
0038  010C' 
0 03A  0B02 
003C  0003 
003E  5E0E 


HILL  BE  RESTORED  WHEN  THE  APPROPRIATE 
CONDITION  IS  FOUND  ! 

CASE  tADVANCE  CALL  THEN 


POP  R2,  2R15 
CALL  ADVANCE 

CASE  # AWAIT  CALL  THEN 


POP  R2,  3R15 
CALL  AWAIT 

CASE  tCREATE  SEG  CALL  THEN 
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0040 

004C* 

0042 

97F2 

POP 

R2,  9B15 

0044 

5F00 

CALL 

CREA  TE_SEG 

0046 

0000* 

0048 

5E08 

CASE 

#DELETE_SEG_CALL 

THEN 

0  04  A 

010C* 

004C 

0B02 

004E 

0004 

0050 

5S0E 

0052 

005E' 

0054 

97F2 

POP 

R2,  2R 1 5 

0056 

5F00 

CALL 

DELETE_SEG 

0058 

0000* 

005A 

5E08 

CASE 

#MAKE_KNOWN_CALL 

THEN 

0  05C 

010C* 

005E 

0B02 

0060 

0005 

0062 

5E0E 

0064 

0070' 

0066 

97F2 

POP 

R2 ,  a)R1 5 

0068 

5F00 

CALL 

MAKE_KNOWN 

0  06  A 

0000* 

006C 

5E08 

CASE 

#RE AD_CALL  THEN 

0  06E 

010C* 

0070 

0B02 

0072 

0006 

0074 

5E0E 

0076 

0082' 

0078 

97P2 

POP 

R2,  a»R15 

007A 

5F00 

CALL 

READ 

00  7C 

0000* 

007E 

5E08 

CASE 

#SM_SWAP_IN_CALL 

THEN 

0080 

010C' 

C  082 

0B02 

0084 

0007 

0086 

5E0E 

0088 

0094* 

008A 

97F2 

POP 

R2,  a)R1 5 

0  08C 

5F00 

CALL 

SM_SHAP_IN 

008E 

0000* 

0090 

5E08 

CASE 

#SM_SHAP_OUT_CALL 

THEN 

0092 

010C' 

0094 

0B02 

0096 

0008 

0098 

5E0E 

009A 

00  A6  ' 

009C 

97F2 

POP 

S2,  a)R1 5 

009E 

5F00 

CALL 

Sa_SHAP_OUT 

00A0 

0000* 

00A2 

5E08 

CASE 

#TERMINATE_CALL 

THEN 

00A4 

010C' 

00A6 

0B0  2 

00A8 

0009 

OOAA 

5E0E 
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OOAC 

OOB8 ' 

00  AE 

97F2 

pop  R2,  aai5 

OOBO 

5F00 

CALL  TERMINATE 

0032 

0000* 

00B4 

5E08 

CASE  #TICKET_CALL  THEN 

00B6 

010C* 

00B8 

0B02 

OOBA 

000  A 

OOBC 

5E0E 

OOBE 

OOCA* 

OOCO 

97F2 

POP  R2,  a>R1 5 

00C2 

5F00 

CALL  TICKET 

00C4 

0000* 

00C6 

5E08 

CASE  #WRITE_CALL  THEN 

00C8 

010C' 

OOCA 

0B02 

OOCC 

OOOB 

OOCE 

5E0E 

OODO 

OQDC' 

00D2 

97F2 

POP  R2,  a)R1 5 

00D4 

5F00 

CALL  WRITE 

00D6 

0FC8 

0  0D8 

5E08 

CASE  #  WR ITELN_CALL  THEN 

OODA 

010C‘ 

0  0  DC 

OBO  2 

OODE 

OOOC 

OOEO 

5E0E 

0  0E2 

OOEE' 

00E4 

97F2 

POP  32,  3R15 

00E6 

5F00 

CALL  WRITELN 

00E8 

OFCO 

OOEA 

5E08 

CASE  #CRLF_CALL  THEN 

OOEC 

010C* 

OOEE 

0B02 

OOFO 

OOOD 

0  0F2 

5E0E 

00F4 

0100‘ 

00F6 

97F2 

POP  R2,  a)R1 5 

00F8 

5F00 

CALL  C3LF 

OOFA 

0FD4 

OOFC 

5E08 

ELSE  ! INVALID  KERNEL  INVOCATION i 

0  OFE 

010C* 

!  RETURN  TO  MONITOR  ! 

!  NOTE:  THIS  RETURN  TO  MONITOR  IS 
FOR  STUB  USE  ONLY.  AN  INVALID 
KERNEL  INVOCATION  WOULD  NORMALL 
RETURN  TO  USER.  ! 

0100 

7601 

LDA  HI,  $ 

0  102 

0100' 

0104 

2100 

LD  RO,  #INVALID_KERNEL_ENTRY 

0106 

OBAD 

0  108 

5F00 

CALL  MONITOR 

0 1  OA 

A90  2 

FI 
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0  1  oc 

0  1  OE 
0  110 


0112 
0  1  14 


0116 

0118 
0  1  1 A 

01  1C 

0  1  IE 
0120 


0122 
0124 
0  126 


!  SAVE  REGISTERS  ON  KERNEL  STACK  1 
•  SAVE  R 1  ! 

93  F 1  PUSH  OR15,  R1 

!  GET  ADDRESS  OF  REGISTER  3 LOCK  J 
34 F 1  LDA  HI,  R15  (#4) 

0004 

!  SAVE  REGISTERS  IN  REGISTER  BLOCK 
ON  KERNEL  STACK.  ! 

1C  1 9  LDM  OR1,  R1,  #16 

0  10F 

!  RESTORE  R1  BUT  MAINTAIN  ADDRESS 
OF  REGISTER  BLOCK  ! 

2DF 1  EX  31,  OR  15 

!  SAVE  R 1  ON  STACK  I 
33F  1  LD  R  1 5  (  #4)  ,  R1 

0004 

!  RESTORE  REGISTER  BLOCK  ADDRESS  ! 
97F1  POP  R1,  OR  1 5 

!  SAVE  VALID  EXIT  SP  VALUE  ! 

33F1  LD  R 15  (#30) ,  HI 

00  IE 

!  EXIT  KERNEL  BY  MEANS  OF  HAEDiARE 
PREEMPT  HANDLER  ! 

5E08  JP  KERNEL_EXIT 

0000* 

END  GATS_KEEPER_MAIN 
END  KERNEL  GATE  KEEPER 
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Z8000 ASM  2.02 

LOC  OBJ  CODE  STMT  SOURCE  STATEMENT 


USER_GATE  MODULE 

SLISTON  $TTY 
CONSTANT 

ADVANCE  CALL  :=  1 

A WAIT_CALL  :=  2 

C  RE AT E_SEG_C ALL  :=  3 

DELETERS  EG _C ALL  : =  4 

MAKE_KNOWN_CALL  :=  5 

READ~CALL  :=  6 

SM_SWAP_IN_CALL  :=  7 

5M_SWAP~OUT_CALL  :=  8 

TERMINATE  CALL  :=  9 

TICKET_C ALL  :=  10 

WHITEHALL  :=  11 

WRITELN  CALL  ;=  12 

CRLF  CALL  :=  13 


GLOBAL 

SSECTION  USER  GATE  PROC 


0000 


0000  7F0 1 
0002  9E08 
0004 


ADVANCE  PROCEDURE 

t  ************************ 

*  PARAMETERS:  * 

*  R1 -.SEGMENT  #  * 

*  R2:  INSTANCE  (ENTRY#)  * 

***************  *******  ** 

*  RETURNS:  * 

*  RO : SUCCESS  CODE  * 

************************ i 

ENTRY 

SC  *ADVANCS_CALL 
RET 

END  ADVANCE 


0004 


0004  7F02 
0006  9S08 
0008 


AWAIT  PROCEDURE 

j  ************************ 

*  PARAMETERS:  * 

*  HI:  SEGMENT  #  * 

*  R2: INSTANCE  * 

*  R R4 : SPECIFIED  VALUE  * 

************************ 

*  RETURNS:  * 

*  RO: SUCCESS  CODE  * 

************************  j 

ENTRY 

SC  # A WAIT_CALL 
RET 

END  AWAIT 
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0008 


0008  7P03 
000A  9E08 
OOOC 


CREATE_SEG  PROCEDURE 

»  ************************ 

*  PARAMETERS:  * 

*  R1:MENT0R_SEG_N0  * 

*  R  2: ENT  RY_NO  * 

*  R3 : SIZ  E  * 

*  RR4  : CLASS  * 

************************ 

*  RETURNS:  * 

*  RO : SUCCESS  CODE  * 

************************ i 

ENTRY 

SC  #CREATE_SEG_CALL 
RET 

END  CREATE  SEG 


OOOC 


OOOC  7F04 
OOOE  9E08 
0010 


DELETE_SEG  PROCEDURE 

j  ************************ 

*  PARAMETERS:  * 

*  R 1 : MENTOR_SEG_NO  * 

*  R2;ENTRY_N0  * 

************************ 

*  RETURNS:  * 

*  RO: SUCCESS  CODE  * 

************************ i 

ENTRY 

SC  #DELETE_SEG_CALL 
RET 

END  DELETE  SEG 


0010 


0010  7F05 
0012  9E08 
0014 


MAKE_KNOWN  PROCEDURE 

i ***************v******** 

*  PARAMETERS:  * 

*  R 1 : MENTOR_SEG_NO  * 

*  R2:ENTRY_N0  * 

*  R 3: ACCESS  DESIRED  * 

************************ 

*  RETURNS:  * 

*  RO : SUCCESS  CODE  * 

*  R 1 : SEG MENT  #  * 

*  R2: ACC  ESS  ALLOWED  * 


************************  j 

ENTRY 

SC  $ MAKE_KNOWN_CALL 
RET 

END  MAKE  KNOWN 


0014  READ  PROCEDURE 

i ************************ 

*  PARAMETERS:  * 

*  R 1:  SEGMENT  #  * 

*  R2: INSTANCE  * 

************************ 
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*  RETURNS:  * 

*  RO: SUCCESS  CODE  * 

*  RR4: EVENTCOUNT  * 

************************ , 

ENTRY 

0014  7F06  SC  #READ  CALL 

00  16  9E0 8  RET 

0018  END  READ 


0018 


0018  7F07 
001A  9E03 
001C 


SM_SWAP_IN  PROCEDURE 

i ************************ 

*  PARAMETERS:  * 

*  R1: SEGMENT  #  * 

************************ 

*  RETURNS:  * 

*  RO: SUCCESS  CODE  * 

************************  i 

ENTRY 

SC  #SM_SWAP_IN_CALL 
RET 

END  SM  SWAP  IN 


00  1C 


001C  7F08 
00  IE  9E08 
0020 


SM_SWAP_OUT  PROCEDURE 

I  ************************ 

*  PARAMETERS:  * 

*  R 1 : SEG  MENT  #  * 

************************ 

*  RETURNS:  * 

*  RO: SUCCESS  CODE  * 

************************  2 

ENTRY 

SC  4 5 M_SW AP_OUT_CALL 
RET 

END  SM  SWAP  OUT 


0020 


0020  7F09 
0022  9E08 
0024 


TERMINATE  PROCEDURE 

t  ************************ 

*  PARAMETERS:  * 

*  R1:  SEGMENT  #  * 

************************ 

*  RETURNS:  * 

*  RO:SUCCESS  CODE  * 

************************  i 

ENTRY 

SC  #TERMI NATE_CALL 

RET 

END  TERMINATE 


0024  TICKET  PROCEDURE 

i ************************ 

*  PARAMETERS:  * 

*  R 1 : SEG  MENT  #  * 

************************ 

*  RETURNS:  * 


315 


*  RO: SUCCESS  CODE  * 

*  RR4 : TICKET  VALUE  * 

ENTRY 


0024 

7F0A 

SC  tTICKET 

_CALL 

0026 

9E0  8 

RET 

0028 

END  TICKET 

0028 

WRITE 

ENTRY 

PROCEDURE 

0028 

7F0B 

SC  #WRITE_ 

CALL 

002A 

9E08 

RET 

002C 

END  WRITE 

0  02C 

WRITELN 

ENTRY 

PROCEDURE 

002C 

7F0C 

SC  # WRITELN  CALL 

002E 

9E08 

RET 

0030 

END  WRITELN 

0030 

CRLF 

ENTRY 

PROCEDURE 

0030 

7F0D 

SC  #CRLF  CALL 

0032 

9E08 

RET 

0034 

END  CRLF 
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Appendix  E 

BOOTSTRAP_LOADER  LISTINGS 


Z3000A3H  2.02 

LOC  OBJ  CODE  STMT  SOURCE  STATEMENT 

BOOTSTR AP_LOADER  MODULE 

SLISTON  $TTY 
CONSTANT 


********  SYSTEM  PARAMETERS  ******** 


N  R_CPU  ;  = 

N  R_V  P  ;  = 

N R_AVA IL  VP  :  = 

MAX_DBR_NR  := 

STACK_SEG  := 

STACK~SEG_SIZE  := 
S  TACK~BLOCK  :  = 

i  *  *  OFFSETS  IN 
S  TACK_BASE 
S  TAT  US _REG_BLOCK :  = 
INTERR UPT_FRAME  := 
I NTERRUPT_REG  := 
N_S_P  ~  := 

F  c~w  : = 


2 

NR_CPU*4 

NR_CPU*2 

10 

1 

X100 

ST ACK_SEG_SI ZE/2  56 

STACK  SEG  *  *  ! 

ST ACK_SEG_SI Z2-% 1 0 
ST  ACK_SEG_SI ZE- X  1 0 
STACK_BASE-4 
INTERRUPTER  AME-34 

interruptIeeg-2 

STACK  SEG  SIZE-4E 


i  ******  SYSTEM  CONSTANTS  ******  ! 


ON 

=  XFFFF 

OFF 

=  0 

READY 

=  1 

NIL 

=  XFFFF 

INVALID 

=  XEEEE 

KSRNEL_FCW 

=  X5QQ0 

AVAILABLE 

=  0 

ALLOCATED 

=  %FF 

SC  OFFSET 

=  12 

TYPE 


MESSAGE  ARRAY  £16  BYTE ] 
ADDRESS  WORD 
MM_VP_ID  WORD 
VP~INDEX  INTEGER 

MSG  INDEX  INTEGER 
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MSGJTABLE  RECORD 
[  MSG 
SENDER 
NEXT_MSG 
FILLER 

] 

V?  TABLE  RECORD 


MESSAGE 
VP_INDEX 
MSG_I NDEX 
ARRAY  £6,  WORD  J 


C 


DBR  ADDRESS 
PRI  WORD 

STATE  WORD 

IDLE_FLAG  WORD 

PREEMPT  WORD 

PHYS_PROCESSOR  WORD 
NEXT  READY  VP  VP  INDEX 


MSG_LIST 
EXT_ID 
FILLER  1 


] 


EXTERNAL 

GET_DBR_ADDR 
CREATE_ST ACK 
LIST_INSERT 
ALLOCATE  MMU 


MS  G_INDEX 
WORD 

ARRA  Y[  7,  WORD] 


PROCEDURE 

PROCEDURE 

PROCEDURE 

PROCEDURE 


UPDATE_MMU_IMAGE  PROCEDURE 
MM_ALLOCATE  PROCEDURE 

MM_ENTRY  LABEL 

I DLE_ENTRY  LABEL 

PREEMPT_RET  LABEL 

BOOTSTRAP_ENTRY  LABEL 
GATEJCEEPER  ENTRY  LABEL 
NEXT_BLOCK  ”  WORD 

MM_CP0_TBL  ARRAY£  NR_CPU  MM_VP_ID] 


VPT  RECORD 

[  LOCK 

RUNNING_LISI 
READ Y_LIST 
FREE_LIST 
V I3T_INT_V  EC 
FILLER_2~ 

VP 

MSG_Q 


WORD 

ARRAY[  NS_CPU  WORD] 

ARRAYC  NR_CPU  WORD] 

MSG  INDEX 
ARRAY£  1#  ADDRESS  ] 

WORD 

ARRAX  [  NR_VP,  VP_TABLE] 

ARRAY  [NR_VP,“MSG_TABLE] 
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0000 

0002 


EXT_VP_LIST  ARRAY[ NR_AVAIL_VP  HORD] 
NEXT_AVAIL_MMU  ARRAY[  MAX_DBR_NR  BYTE] 


PRDS  RECORD 


[PHYS_CPU_ID  WORD 
LOG  CPU  ID  INTE 


INTEGER 

HORD 

VP_INDEX] 


YP  NR 
IDLE  VP 


INTERNAL 

$  SECTION  LOADER_DAT A 

!  NOTE:  THESE  DECLARATIONS  HILL  NOT  HORK 
IN  A  TRUE  MULTIPROCESSOR  ENVIRONMENT  AS 
THEY  ARE  SUBJECT  TO  A  "CALL."  THEY  MUST 
BE  DECLARED  AS  A  SHARED  GLOBAL  DATABASE 
HITH  "RACE"  PROTECTION  (E.G. ,  LOCK).  ! 

NEXT_AVAIL_VP  INTEGER 
NEXT  EXT  VP  INTEGER 


0000 

0002 


319 


$SECT ION  LOAD  ER_INT 
INTERNAL 

0000  BOOTSTRAP  PROCEDURE 

i  *  ******************************* 

*  CREATES  KERNEL  PROCESSES  AND  * 
INITIALIZES  KERNEL  DATABASES.* 


* 

* 

* 

* 

4c 

♦ 

4c 


INCLUDES  INITIALIZATION  OF 
VIRTUAL  PROCESSOR  TABLE , 
EXTERNAL  VP  LIST,  AND  MMU 
IMAGES.  ALLOCATES  MMU  IMAGE 
AND  CREATES  KERNEL  DOMAIN 
STACK  FOR  KERNEL  PROCESSES. 


* 

* 

★ 

* 

♦ 

★ 


***************************** *  *  *  f 


0000  4D05 
0002  0000* 
0004  FFFF 


00  IE  7D15 


0020  0101 
0022  000C 

0024  0D15 
0026  5000 


0028  A91 1 


ENTRY 

!  INITIALIZE  PROS  AND  MHO  POINTER  I 
!  NOTE:  THE  FOLLOWING  CONSTANTS  ARE 
ONLY  TO  BE  INITIALIZED  ONCE.  THIS 
WILL  OCCUR  DURING  SYSTEM  INITIALIZATION! 
LD  PRDS.  PHYS_CPU_ID,  #XFFFF 


!  NOTE:  LOGICAL  CPU  NUMBERS  ARE  ASSIGNED 
IN  INCREMENTS  OF  2  TO  FACILITATE  INDEXING 
(OFFSETS)  INTO  LISTS  SUBSCRIPTED  BY 
LOGICAL  CPU  NUMBER.  ! 


0006 

0008 

000A 

4D05 

0002* 

0002 

LD 

j 

PRDS. LOG_CPU_ID,  #2 

SPECIFY  NUMBER  OF  VIRTUAL  PROCESSORS 
ASSOCIATED  WITH  PHYSICAL  CPU.  ! 

OOOC 
0  00E 
0010 

4D05 

0004* 

0002 

LD 

?RDS.VP_NR,  #2 

0012 
00  14 

4D08 

0000* 

CLR 

NEXT_3LOCK 

0016 

0018 

4D08 

OCOO* 

CLR 

NEXT_AVAIL_VP 

0  0 1 A 
00  1C 

4D08 

0C02* 

CLR 

NEXT_EXT_VP 

!  ESTABLISH  GATE  KEEPER  AS  SYSTEM  CALL 

TRAP  HANDLER  ! 

!  GET  BASE  OF  PROGRAM  STATUS  AREA  ! 

LDCTL  R 1  ,  PSAP 

!  ADD  SYSTEM  CALL  OFFSET  TO  PSA  BASE  ADDR  ! 
ADD  R1,  #SC_OFFSET 

!  STORE  KERNEL  FCW  IN  PSA  ! 

LD  SRI,  #KER  NEL_FCW 

!  STORE  ADDRESS  OF  GATE  KEEPER  IN  PROGRAM 
STATUS  AREA  AS  SYSTEM  TRAP  HANDLER  ! 

INC  Rl,  #2 
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002A 

0D15 

LD 

dfil,  #G AT  E_KEEPE3  ENTRY 

002C 

0000* 

002E 

8D18 

CLR 

R1  !  NEXT_AVAIL_MMU  INDEX  ! 

!  INITIALIZE  ALL  MMU  IMAGES  AS  AVAILABLE  1 
SET  MMU  MAP: 


DO 


0030 

0032 

4C15 

0000* 

LDB 

NEXT_AVAIL_MMU(R1)  ,  # AVAILABLE 

0034 

0000 

0036 

A910 

INC 

R1,  #1 

!  CHECK  FOR  END  OF  TABLE  ! 

0038 

0B0 1 

CP 

R1  t  *max_dbr_nr 

003A 

000  A 

003C 

5E0E 

IF  EQ 

THEN  EXIT  FROM  SET_MMU_MAP  FI 

003E 

0044' 

0040 

5E08 

0042 

0046' 

0044 

E8F5 

OD 

!  CREATE 

MEMORY  MANAGER  PROCESS  I 

0046 

2103 

LD 

R3,  #STACK_BLOCK 

0048 

0001 

!  ALLOCATE  AND  INITIALIZE  KERNEL 

DOMAIN 

STACK  SEGMENT  ! 

004  A 

5F00 

CALL 

MM_ALLOCA TE  !R3;  #  OF  BLOCKS 

004C 

0000* 

RETURNS 

R2:  START  ADDRJ 

004E 

A121 

LD 

HI,  R2 

0050 

2103 

LD 

R3,  #KERNEL_FCW 

0052 

5000 

0054 

7604 

LDA 

R4,  aa_ENTRY 

0056 

0000* 

0058 

6105 

LD 

R5,  XFFFF  i NSP ! 

005A 

FFFF 

005C 

7606 

LDA 

R6,  PREEMPT_RET 

0  05E 

0000* 

0060 

93F1 

PUSH 

3R15,  R 1  !SAVE  STACK  ADDR ! 

0062 

030F 

SUB 

R1 5,  #8 

0064 

0008 

0066 

1CF9 

LDM 

SR15,  R3,  #4 

0068 

0303 

006  A 

A1F0 

LD 

RO,  R 1 5 

!  NOTE:  ARGLIST  FOR  CREATE_STACK  INCLUDES 

KERNEL 

FCW,  INITIAL  IC,  NSP,  AND  INITIAL 

return" 

'POINT.  1 

006C 

5F00 

CALL 

CREAT3_STACK  !  (RO:  ARGUMENT  PTR 

006E 

0000* 

R 1 ;  TOP  OF  STACK 
R2-R14:  INITIAL 
REG. STATES  ! 
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R15,  #8  IOVERLAY  ARGUMENTS.' 


0070 

0072 

0074 

0076 

0078 
0  07A 
0  0  7C 
007E 
0080 


0082 

0084 

0086 


0088 

008A 


008C 


008E 

0090 


0092 

0094 

0096 

0098 

009A 

009C 


009E 
00  AO 


00A2 

00A4 


0 1 0  F  ADD 

0008 

I  ALLOCATE  M MU_IM AGE  l 

5F00  CALL  ALLOCAT E_MM U  I  RETURNS: 

0000* 


(RO:  DBR  #)  1 


2101 

LD 

R 1 ,  #STACK_SEG  !  SEGMENT  NO. 

0001 

97  F  2 

POP 

R2,  a)R  1  5  !  GET  STACK  ADDR! 

2103 

LD 

R3,  #0  !  WHITE  ATTRIBUTE  ! 

0000 

!  SPECIFY  NUMBER  OF  BLOCKS.  COUNT  STARTS 

FROM 

ZERO.  (I.E.,1  BLOCK=0,  2  =  1,  ETC.)1 

2104 

LD 

R4 ,  #STACK_BLOCK- 1 

0000 

!  SAVE 

DBR  *  ! 

93F0 

PUSH 

a>R  15,  RO 

I  CREATE  MMU  ENTRY  FOR  MM  STACK  SEGMENT  • 

5F00  CALL  UPDATE_MMU_IM AGE  ! (RO:  DBR  # 

0000* 

R 1:  SEGMENT  # 

R2:  SEG  ADDRESS 
R3:  SEG  ATTRIBUTES 
R4:  SEG  LIMITS)  i 

l  RESTORE  DBR  #  ! 

97F0  POP  RO,  a)R  15 

!  GET  ADDRESS  OF  MMU  IMAGE  ! 

5F00  CALL  GET_DBR_A  DDR  (RO;  DBR  #) 

0000* 

RETURNS: 

(R1:  DBR  ADDRESS)  ! 
!  PREPARE  VP  TABLE  ENTRIES  FOR  MM  i 


2102 

0002 

LD 

R2, 

#2 

!  PRIORITY  ! 

2105 

0000 

LD 

R5, 

#OFF 

!  PREEMPT  1 

2106 

0000 

LD 

R6  , 

#OFF 

l  KERNEL  PROCESS  ! 

!  UPDATE  VPT  ! 

5F00  CALL  UPDAIE_VP  TABLE  !  (R 1 :  DBR 

0 1CA ' 

R2:  PRIORITY 
R5:  PREEMPT  FLAG 
R6;  EXT_VP  FLAG) 
RETURNS? 

R9:  VP_ID  I 

!  INITIALIZE  MM_CPU_TBL  IN  DISTRIBUTED  MEMORY 
MANAGER  WITH  VP  ID  OF  MM  PROCESS  ! 

!  GET  LOGICAL  CPU  #  ! 

610A  LD  RIO,  PHDS . LOG_CPU  ID 

0002* 
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00A6 

6FA9 

LD 

MM_CPU_TBL  (RIO)  ,  R9 

00A8 

0000* 

!  CREATE 

IDLE  PROCESS  ! 

OOAA 

2103 

LD 

R3 ,  #  ST  AC  K_BLOCK 

OOAC 

0001 

00  AE 

5F00 

CALL 

MM_ALLOCATE  !R3:  #  OF  BLOCKS 

OOBO 

0000* 

RETURNS 

R2;  START  ADDR! 

00B2 

A121 

LD 

HI,  R2 

0  0B4 

2103 

LD 

R3 ,  #KERN  EL_FCW 

00B6 

5000 

00B8 

7604 

LDA 

H4,  IDLE_ENTRY 

OOBA 

0000* 

OOBC 

2105 

LD 

R5,  #SFFFF  JNSP! 

OOBE 

FFFF 

OOCO 

7606 

LDA 

R6,  PREEMPT_RET 

0  0C2 

0000* 

00C4 

93F 1 

POSH 

«R15,  R 1  ’SAVE  STACK  ADDR! 

00C6 

03  OF 

SUB 

R15,  #8 

00C8 

0003 

OOCA 

1CF9 

LDM 

a>R  1 5,  R3,  #4 

OOCC 

0303 

OOCE 

A1F0 

LD 

RO,  R 1 5 

!  INITIALIZE  IDLE  STACK  VALUES  ! 

OODO 

5P00 

CALL 

CREATE_STACK  !  (RO:  ARGUMENT  PTR 

00D2 

0000* 

R1 ;  TOP  OF  STACK 
R2-R14:  INITIAL 
REG.  STATES  ! 

00D4 

010F 

ADD 

R15,  #8  !OVERLAY  ARGUMENTS! 

00D6 

0008 

!  ALLOCATE  MMU  IMAGE  FOR  IDLE  PROCESS  ! 

00D8 

5F00 

CALL 

ALLOCATE_MMU  !  RETURNS  R 0: DBR  #  ! 

OODA 

0000* 

!  PREPARE 

IDLE  PROCESS  MMU  ENTRIES  ! 

OODC 

2101 

LD 

HI,  #  ST ACK_SEG  !  SEG  #  ! 

OODE 

0001 

00  EO 

97F2 

POP 

R2  ,  a>R  1  5  !  GET  STACK  ADDR! 

00E2 

2103 

LD 

R3,  #0  !  MRITE  ATTRIBUTE 

00E4 

0000 

00E6 

2104 

LD 

R4 ,  *STACK_BLOCK- 1  !  BLOCK  LIMITS 

00E8 

0000 

!  SAVE  DBR  #  t 

OOEA 

93F0 

PUSH 

dR15,  RO 

!  CREATE 

MMU  IMAGE  ENTRY  ! 

00  EC 

5F00 

CALL 

UPDATE_MMU_IMAGE  !  (R  1 :  SEGMENT  # 

OOEE 

0000* 
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R2:  SEG  ADDRESS 
S3:  SEG  ATTRIBUTES 


E4 :  S EG  LIMITS  ) 


i 


!  RESTORE 

DBR  #  ! 

OOFO 

97F0 

POP 

RO,  3R15 

!  GET  MMU 

ADDRESS  1 

00F2 

5F00 

CALL 

GET_DBR_ADDR  ! 

(RO:  DBR  #) 

0  0F4 

0000* 

RETURNS 

(R 1 :  DBR  ADDRESS)  ! 

!  PREPARE 

VPT  ENTRIES  FOR 

IDLE  PROCESS  ! 

00F6 

2102 

LD 

R2 ,  #0 

!  PRIORITY  ! 

00F8 

0000 

OOFA 

2105 

LD 

R5,  #OFF 

I  PREEMPT  ! 

0  OFC 

0000 

00  FE 

2106 

LD 

R6  ,  #OFF 

I  KERNEL  PROC  ! 

0100 

0000 

!  CREATE  VPT  ENTRIES  I 

0102 

5F00 

CALL 

UPDATE_VP_TABLE 

I  (R 1  ;  DBR 

0104 

01CA' 

R2:  PRIORITY 

R4 :  IDLE_FL AG 

R5;  PREEMPT 

R6 :  EXT_VP  FLAG) 
RETURNS: 

R9 :  VP  ID  i 

!  ENTER  VE 

•  ID  OF  IDLE  PROCESS  IN  PRDS  ! 

0106 

6F09 

LD 

PRDS.IDLE_VP,  R9 

0100 

0006* 

!  INITIALIZE  IDLE  VP'S  I 

0  1  0  A 

2102 

LD 

R2 ,  #1 

!  PRIORITY  ! 

010C 

0001 

0  1  OE 

2105 

LD 

R5,  #0N 

!  PREEMPT  ! 

0110 

FFFF 

0112 

2106 

LD 

R6 ,  #0N 

! NO N- KERNEL  PROC! 

0  114 

FFFF 

0116 

6100 

LD 

RO,  PRDS. VP_NR 

0  1  18 

0004* 

!  INITIALIZE  VP  VALUES  ! 

DO 

01  1A 

5F00 

CALL 

UPDATE_VP_I ABLE 

!  (HI  :  DBR 

0  1  1C 

01CA* 

R2:  PRIORITY 

R4;  IDLE  FLAG 

R5:  PREEMPT 

R6:  EXT_VP  FLAG) 
RETURNS: 

R9:  VP_ID  i 

0  1  IE 

ABOO 

DEC 

RO,  #1 

0120 

OBOO 

CP 

RO,  #0 

0122 

0000 

0124 

5E0E 

IF  EQ  ! ALL 

,  VP'S  INITIALIZED !  THEN 

0126 

012C* 

0128 

5E08 

EXIT 
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012A  0 1 2E* 


FI 

012C  E8F6  OD 

!  INITILIZE  VPT  HEADER  i 


i  GET  LOGICAL  CP(J  HUMBER  ! 

012E 

6102 

LD 

R2,  PROS. LOG_CPU_ID 

0130 

0002* 

0  132 

4D05 

LD 

VPT. LOCK,  #OFF 

0134 

0000* 

0136 

0000 

0138 

4D25 

LD 

VPT.RUNNING_LIST (R2)  ,  #NIL 

0  13A 

0002* 

013C 

FFFF 

013E 

4D25 

LD 

VPT.READY_LIST(R2)  ,  #NIL 

0140 

0006* 

0  142 

FFFF 

0144 

4D0  8 

CLR 

VPT.FREE_LIST  .'HEAD  OF  MSG 

LIST! 

0  146 

000  A* 

! THREAD  VP'S 

BY  PRIORITY  AND  SET  STATES  TO  READY  ! 

0148 

8D28 

CLR 

R2  ! START  WITH  VP  # 1 i 

THREAD: 

DO 

0  14A 

6  1 0D 

LD 

R 1 3,  PRDS.LOG_CPU_ID 

014C 

0002* 

014E 

76D3 

LD  A 

R3 , VPT. RE ADY_LIST (R 1 3 ) 

0150 

0006* 

0  152 

7604 

LD  A 

R4 , VPT. VP .NEXT_READY_VP 

0154 

001C* 

0156 

7605 

LDA 

R5,VPT.  VP.PRI 

0158 

0012* 

0  15A 

7606 

LD  A 

R6,  VPT.  VP. STATE 

015C 

0014* 

0  15E 

2107 

LD 

R7, VREADY 

0160 

0001 

!  SAVE 

OBJ  ID  ! 

0162 

93F2 

POSH 

3R15,  R2 

0164 

5F00 

CALL 

LIST.INSERT  1R2:  OBJ  ID 

0166 

0000* 

S3:  LIST.HEAD 

PTR  ADDR 

R4:  NEXT_OB J 

PTR 

R5:  PRIORITY, 

PTR 

R6:  STA  TE_PTR 

R7:  STATE  ! 

!  RESTORE  OBJ  ID  ! 

0168 

97F2 

POP 

R2  f  a)R  1  5 

0  16A 

0102 

ADD 

82,  #SIZEOF  VP_TA3LE 

016C 

0020 

0  16E 

0B02 

CP 

R2,  *  (NR_VP  *  (SIZEOF  VP_TA8LE) ) 

0170 

0100 

0172 

5E0E 

IF  EQ  1 

THEN  EXIT  FROM  THREAD  FI 

0174 

0 17  A 1 
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0176 

5E08 

0  178 

017C* 

0  17A 

E8E7 

OD 

!  INITIALIZE  VP  MESSAGE  LIST  » 

!  NOTE:  ONLY  THE  THREAD  FOR  THE  MESSAGE 

LIST  NEED  BE  CREATED  AS  ALL  MESSAGES 

ARE  INITIALLY  AVAILABLE  FOR  USE.  THE 

INITIAL 

MESSAGE  VALUES  HERE  CREATED 

FOR  CLARITY  ONLY  TO  SHOW  THAT  THE 

MESSAGES 

HAVE  NO  USABLE  INITIAL  VALUEI 

0  1  7C 

8D1 8 

CLR 

HI 

MSG. 

_LST_INIT: 

!  NOTE:  R 1 

REPRESENTS  CURRENT  ENTRY  IN 

MSG  LIST 

,  R 2  REPRESENTS  CURRENT  POSITION 

IN  MSG_LIST  ENTRY,  AND  R3  REPRESENTS 

NEXT  ENTRY  IN  MSG_LIST.  ! 

DO 

0  17E 

A1 12 

LD 

R2,  R  1 

0180 

A123 

LD 

R3,  R2 

0  182 

0103 

ADD 

R3,  ISIZEOF  MESSAGE 

0184 

0010 

FILL  MSG: 

DO 

0  186 

4D25 

LD 

VPT.MSG_Q.MSG  (R2)  ,  ^INVALID 

0188 

0110* 

0  1  8  A 

EEEE 

018C 

A92 1 

INC 

R2,  #2 

0  1 8  E 

8B32 

CP 

R2,  R3 

0190 

5E0E 

IF  EQ  THEN  EXIT  FROM  FILL  MSG  FI 

0192 

0198' 

0194 

5E08 

0196 

019A* 

0198 

E8F6 

OD 

0  1  9  A 

4D15 

LD 

VPT. MSG_Q. SENDER (R1> ,  #NIL 

019C 

0120* 

0  19E 

FFFF 

01  AO 

A112 

LD 

R2,  R 1 

0  1  A2 

0101 

ADD 

R 1 ,  tSIZEOF  MSG_TABLE 

01A4 

0020 

0  1  A6 

0B0  1 

CP 

R 1 ,  #SIZEOF  MSG_T ABLE*NR_  VP 

01  A8 

0100 

IF  EQ 

0  1  AA 

5E0E 

THEN 

0  1  AC 

0  1BC' 

01  AE 

4D25 

LD 

VPT.MSG_Q.NEXT_MSG (R2) ,  #NIL 

0  1  BO 

0122* 

0  1B2 

FFFF 

0184 

5E08 

EXIT  FROM  MSG  LST  INII 

01B6 

01C2» 

0  1B8 

5E08 

ELSE 

0  1  BA 

01C0' 

0  1  BC 

6F2 1 

LD 

VPT.MSG_Q.NEXT_MSG (R2) ,  HI 
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0 1  BE  0122* 


FI 


01C0  E8DE  OD 


01C2  6 1 OD 
01C4  0002* 


0 1C6  5E08 
0 1C8  0000* 
0  1 CA 


I  GET  LOGICAL  CPU  #  FOR  USE 
BY  ITC  GETWOEK.  ! 

LD  S  1 3,  PRDS. LOG_CPU_ID 

!  BOOTSTRAP  COMPLETE  ! 

!  START  SYSTEM  EXECUTION  AT  PREEMPT  ENTRY  ! 
!  POINT  IN  ITC  GETWORK  PROCEDURE  ! 

JP  BOOTSTRAP_ ENTRY 

END  BOOTSTRAP 
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01CA  U  PDATE_VP_TA  BLE  PEOCEDUBE 

1 ******************************** 


* 

INITIALIZES  V ?T  ENTRIES 

* 

******************************** 

* 

REGISTER  USE: 

* 

* 

PARAMETERS: 

* 

* 

R 1  : 

DBR  ADDRESS 

* 

* 

R2: 

PRIORITY 

3* 

* 

R5 : 

PREEMPT  FLAG 

* 

* 

R6 : 

EXTERNAL  VP  FLAG 

* 

* 

RETURNS: 

* 

* 

R9: 

ASSIGNED  VP  ID 

3* 

* 

LOCAL  VARIABLES: 

* 

* 

R7: 

LOGICAL  CPU  # 

3* 

* 

R8 : 

EXT_VP_LIST  OFFSET 

3* 

* 

R9: 

VPT  OFFSET 

3* 

********************************  f 

ENTRY 

t 

GST  OFFSET  IN  VPT  FOR  NEXT 

ENTRY  ! 

0  1CA 

6109 

LD 

39,  NEXT_AVAIL_VP 

01CC 

0000  • 

0  ICS 

6F91 

LD 

VPT. VP.  DBR  (R9)  ,  R1 

0  1  DO 

0010* 

01D2 

6F92 

LD 

VPT.VP.PRI(R9)  ,  R2 

01D4 

0012* 

0  1D6 

6F96 

LD 

VPT.  VP.  IDLE  FLAG  (R9)  ,  R6 

01D8 

00  16* 

0  1  DA 

6F95 

LD 

VPT.  VP.  PREEMPT  (B9)  , 

R  5 

01  DC 

0018* 

0  1  DE 

6107 

LD 

R7  ,  PRDS.  LOG_CPU_ID 

0  1E0 

0002* 

01E2 

6F97 

LD 

VPT.  VP.  PHYS  PROCESSOR  (R9)  ,  R7 

0  1E4 

00  1  A* 

0  1E6 

4D95 

LD 

VPT. VP.  NEXT  READY  VP(R9),  #NIL 

01E8 

001C* 

0  1  EA 

FFFF 

0  1  EC 

4D95 

LD 

VPT.  VP.  MSG_LIST  (R9) 

,  #NIL 

0  1  EE 

00  IE* 

0  1  FO 

FFFF 

• 

CHECK 

EXTERNAL  VP  FLAG  » 

01F2 

0306 

CP 

R6 ,  #ON 

0  1F4 

FFFF 

IF  EQ  ! 

EXTERNAL  VP! 

01F6 

5E0E 

THEN  ! 

VP  IS  TC  VISIBLE  i 

01F8 

0210* 

0  1  FA 

6108 

LD 

38 ,  NEXT_SXT_VP 

0  1 FC 

0002' 

!  INSERT  ENTRY  IN  EXTERNAL 

VP  LIST  ! 

0  1  FE 

6F89 

LD 

EXT_VP_LIST(R8)  ,  R9 

0200 

0000* 

0202 

6F98 

LD 

VPT.  VP.  £XT_ID  (R9)  , 

38 

0204 

0020* 
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0206 

A981 

INC 

R8  , 

#2 

0208 

6F08 

LD 

NEXT 

_EXT_VP,  R8 

020A 

0002' 

0  20C 

5E08 

ELSE  ! 

VP  BOUND  TO  KERNEL  PROCESS 

0  20E 

0216* 

0210 

4D05 

LD 

VPT. 

VP. EXT_ID,  #NIL 

0212 

0020* 

0214 

FFFF 

FI 

0216 

A19A 

LD 

RIO, 

R9 

0218 

01 0  A 

ADD 

RIO, 

#SIZEOF  VP_TABLE 

0  2  1 A 

0020 

02  1C 

6F0  A 

LD 

NEXT 

_AVAIL_VP,  RIO 

0  2  1 E 

0000' 

0220 

9E08 

RET 

0222 

END  UPDATE 

_VP_TABLE 

END  BOOTSTRAP  LOADER 
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Appendix  F 


LIBRARY  FUNCTION  LISTINGS 


zaooOAsa  2.02 

LOC  OBJ  CODE  STMT  SOURCE  STATEMENT 

L IBR  ARY_FU  NCTIO  N  MODULE 

SLISTON  $TTY 

CONSTANT 
KER  NE  L_PCW 
STACK  SEG_SIZE 
5TACK_3Ao5 
STATUS_REG_BLOCK 
INTERRUPT  FRAME 
I NTERRUPT_REG 
N_S_P 
NIL 


=  X100 

=  STACK_5EG_SIZE-S 10 

=  stackIsegIsizb-sio 

=  STACK_BASE-4 
=  INTERRUPT_FRAME- 34 

=  interruptIreg-2 

=  SFFFF 
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SSECTION  LIB_PROC 
GLOBAL 


0000 


0016  005A ' 


0022 

0024 

0026 

0028 

002A 

002C 

002E 


5E02 

0030' 

2F32 

7348 

0200 

5E08 

005A ' 


LISI_IN  SERT  PROCEDURE 

i  ******************** ************* 

*  INSERTS  OBJECTS  INTO  A  LIST  * 

*  BY  ORDER  OF  PRIORITY  AND  SETS  * 

*  ITS  STATE  * 

********************************* 


*  REGISTER  USE: 

*  PARAMETERS: 

*  R2:  OBJECT  ID 


* 

* 

* 


* 

R3: 

HE AD_OF_LIST_PTR  ADDR 

* 

* 

R4; 

NEXT_OBJ_PTR  ADDR 

* 

* 

R5: 

PRIORITYlPTR  ADDR 

* 

* 

R6 : 

STATE  PTR  ADDR 

* 

* 

R7: 

OBJECT  STATE 

* 

* 

LOCAL  VARIABLES: 

* 

* 

R8: 

HEAD_OF_LI ST_PTR 

* 

* 

R9: 

NEXT~OBJ_PTR_ 

* 

* 

RIO 

:  CURRENT  OBJ  PRIORITY 

* 

* 

R  1  1 

:  NEXT  OBJ  PRIORITY 

* 

******************************** *f 

ENTRY 

!  GET  FIRST  OBJECT  IN  LIST  ! 

0000 

2138 

LD 

R8,  a>R3 

0002 

0B08 

CP 

R8,  #  NIL 

0004 

FFFF 

0006 

5E0E 

IF 

EQ  ! 

LIST  IS  EMPTY!  THEN 

0008 

00  18' 

i 

PLACE  OBJ  AT  HEAD  OF  LIST  ! 

OOOA 

2F32 

LD 

a)R3,  R2 

OOOC 

7449 

LDA 

R9,  R4(R2) 

OOOE 

0200 

0010 

0D95 

LD 

SR9,  #NIL 

0012 

FFFF 

0014 

5E08 

ELSE 

!  COMPARE  OBJ  PRI  WITH  LIST  HEAD  PRI  ! 


0018 

715A 

LD 

RIO, 

R5(R2)  !  OBJ  PRI! 

00  1A 
00  1C 

0200 

715B 

LD 

R  1 1  , 

R5  (R8)  !  HEAD  PRI! 

001E 

0020 

0800 

8BBA 

CP 

RIO, 

R1  1 

IF  GT  ! OBJ  PRI>HEAD  PRI!  THEN 


LD 

LD 


5>R3,  R2  ! PUT  AT  FRONT! 
R4 (R2)  ,  R8 


ELSE  !  INSERT  IN  BODY  OF  LIST  ! 


SEARCH  LIST: 
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DO 


0030 

0B08 

CP 

0032 

FFFF 

0034 

5E0E 

IF  EQ 

!  END 

0036 

003C' 

0038 

5E08 

EXIT 

FROM 

003k 

0052* 

FI 

0  03C 

715B 

LD 

0  03E 

0800 

0040 

8BBA 

CP 

0042 

5E0  2 

IF  GT 

!  COB 

0044 

004A* 

0046 

5E08 

EXIT 

FROM 

0048 

0052* 

FI 

!  GET 

NEXT 

004A 

A189 

LD 

004C 

7148 

LD 

0  04E 

0900 

0050 

E8EF 

OD  ! 

END 

!  INSERT  IN 

0052 

7348 

LD 

0054 

0200 

0056 

7342 

LD 

0058 

0900 

FI 


005A 

7367 

FI 

!  SET  OBJECT'S 
LD 

005C 

005E 

0200 

9E08 

RET 

0060 

END  LIST  INSERT 

R8,  #  NIL 
OF  LIST!  THEN 
SEARCH_LIST 

Ell,  R5(R8)  'GET  NEXT  PHI 
RIO,  SI  1 

BENT  PRI>NEXT  PRI!  THEN 
SEARCH_LIST 

OBJ  ! 

R9 ,  R8 
R8,  R4(R9) 

SEARCH_LIST  ! 

LIST  ! 

R4  (R2)  ,  R8 

R4(R9),  R2 

STATE  ! 

R6(R2),  R7 
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0060 


CREATE_STACK  PROCEDURE 

*  INITIALIZES  KERNEL  STACK  * 

*  SEGMENT  FOE  PBOCESSES  * 

********  *  *****  *  *  *  *  *  $  *  *  *  *  4c  %  *  *  *  4c  *  4c 

*  B EGISTEB  USE:  * 

*  PABAMETEBS:  * 

*  BO:  ABGUMENT  POINTEB  * 

*  (INCLUDES:FCW,IC,NSP,  AND  * 

*  RETURN  POINT.  SEE  LOCAL  * 

*  VARIABLES  BELOW.)  * 

*  R1:  TOP  OF  STACK  * 

*  R2-R1 4:  INITIAL  REGISTER  * 


STATES.  (NOTE:  IN  DEMO,  NO  * 
SPECIFIC  INITIAL  REGISTER  * 
VALUES  ARE  SET,  EXCEPT  R13* 


*  (USER  ID)  FOR  USER  PRO-  * 

*  CESSES.)  * 

******  ************************** 

*  LOCAL  VARIABLES  * 

*  (FROM  ARGUMENTS  STORED  ON  * 

*  STACK.)  * 

*  R3:  FCW  * 

*  R4  :  PROCESS  ENTRY  POINT  (IC)  * 

*  R5:  NSP  * 

*  R6:  PREEMPT  RETURN  POINT  * 


******************************* *j 


ENTRY 


0060 

93F0 

PUSH 

3R15,  RO  !S  AVE  ARGUMENT  PTRi 

0062 

ADFO 

EX 

RO,  R15  !SAVE  SPi 

0064 

34  IF 

L  DA 

R 1  5,  R1  (#INTERRUPT_REG) 

0066 

OOCA 

0068 

1CF9 

LDM 

SR15,  R 1 ,  #16  ! INITI AL  REG.  VALUES 

006  A 

0 10F 

I  NOTE: 

ONLY  REGISTERS  R2-B14  MAY  CONTAIN 

INITIALIZATION  VALUES  ! 

006C 

A 1 0F 

LD 

R15,  RO  IRESTORE  SP! 

006E 

97F0 

POP 

RO,  SRI  5  'RESTORE  ARGUMENT  PTRI 

0070 

A1FE 

LD 

R  1  4 ,  B  1  5  .'SAVE  CALLER  RETURN  POINT! 

0072 

A10F 

LD 

R15,  RO  I  GET  ARGUMENT  PTRI 

0074 

1CF  1 

LDM 

R3,  SR15,  #4  ILOAD  ARGUMENTS! 

0076 

0303 

0078 

34  IF 

L  DA 

S 1 5,  R1  (# INTERRUPT_FR AME) 

007A 

OOEC 

00  7C 

1CF9 

LDM 

SR  15,  R3,  #2  UNIT  IRET  FRAME! 

007E 

0301 

0080 

34  1 F 

L  DA 

R15,  R 1  (#N_S_P) 

0082 

00C8 

0084 

2FF5 

LD 

SR  15,  R5  ! SET  NSP! 

0086 

030F 

SUB 

R15,  #2 

0088 

0002 

008A 

2FF6 

LD 

SR  1 5,  R6  !PREEMPT  RET  POINT! 

008C 

3418 

LDA 

R8,  R1  (  #S  TACK_B  ASE) 
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0 08E  OOFO 

!  INITIALIZE  STATUS  REGISTER  BLOCK  ! 


0090 

0092 

2100 

5000 

LD 

BO, 

0094 

0096 

1C89 

0F01 

LDM 

3R8, 

0098 

A 1  EF 

LD 

R 1  5, 

009A 

9E08 

RET 

009C 

END  CREATE 

STACK 

END  LIBRARY  FUNCTION 


KERN  EL_FCW 

R15,  #2  1SAVE  SP  S  FCW! 

R  1  4  ! RESTORE  RETURN  POINT! 


Appendix  G 

inner  traffic  controller  listings 

Z8000 ASM  2.02 

LOC  OBJ  CODE  STMT  SOURCE  STATEMENT 

INNER_TRAFFIC_CONTROL  MODULE 
SLISTON  $TT  Y 


!  **  1  .  GETWORK: 

A.  NORMAL  ENTRY  DOES  NOT  SAVE  REGISTERS. 

(  THIS  IS  A  FUNCTION  OF  THE  GATEKEEPER  ). 

B.  R14  IS  AN  INPUT  PARAMETER  TO  GETWORK  THAT 
SIMULATES  INFO  THAT  WILL  EVENTUALLY  BE  ON 
THE  MMU  HARDWARE.  THIS  REGISTER  MUST  BE 
ESTABLISHED  AS  A  DBR  BY  ANY  PROCEDURE 
INVOKING  GETWORK. 

C.  THE  PREEMPT  INTERRUPT  ENTRY  HANDLER  DOES 
NOT  USE  THE  GATEKEEPER  AND  MUST  PERFORM 
FUNCTIONS  NORMALLY  ACCOMPLISHED  BY  IT 
PRIOR  TO  NORMAL  ENTRY  AND  EXIT. 

(  SAVE/RESTORE:  REGS,  NSP;  UNLOCK  VPT,  TEST  INT) 

2.  GENERAL: 

A.  ALL  VIOLATIONS  OF  VIRTUAL  MACHINE  INSTRUCTIONS 
ARE  CONSIDERED  ERROR  CONDITIONS  AND  WILL  RETURN 
SYSTEM  TO  THE  MONITOR  WITH  AN  ERROR  CODE  IN  RO 
AND  THE  PC  VALUE  IN  R1 . 

B.  ITC  PROCEDURES  CALLING  GETWORK  PASS  DBR 
(REGISTER  R 1 4 )  AND  LOGICAL  CPU  NUMBER 
(REGISTER  R 1 3)  AS  INPUT  PARAMETERS. 

(INCLUDES:  SIGNAL,  WAIT,  SWAP_VDBR, 

PHYS  PREEMPT_HANDLEE,  AND  IDLE) .  ! 


CONSTANT 

t  ********** 


U_  L 

M  L  EM 

mIlIsr 

R_L_E 
M~  L_0 

s~n"a 

V~I  E 
M~U~ 


0 

1 

2 

3 

4 

5 

6 
7 


ERROR  CODES  **********  J 
!  UNAUTHORIZED  LOCK  ! 
MESSAGE  LIST  EMPTY  ! 
MESSAGE  LIST  ERROR  ! 
READY  LIST  EMPTY  ! 
MESSAGE  LIST  OVERFLOW 
SWAP  NOT  ALLOWED  ! 

VP  INDEX  ERROR  ! 

MMU  UNAVAILABLE  ! 
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•  ********  SYSTEM 
NR_SDR  : 

NR  CPU  : 

NR~  VP  : 

NR_ AV  AIL_VP  r 

MAX_DBR_NR  :  = 

ST ACK_SEG 
PR DS  SEG  :: 

STACK  SEG  SIZE  :■ 


PARAMETERS  ********  I 
64  'LONG  WORDS! 

2 

N  R_CPU*4 
N  R_CPU*2 
10  ! PER  CPU! 

1 

0 

35100 


»  *****  OFFSETS  IN  STACK  SEG  *****  ! 


STACK_BASE  :=  STACK_SEG_S IZE- 35  10 

STATU  S_REG_BLOCK : =  ST ACK'sEG^SIZE- %  10 
INTER RUPT_F RAM E  :=  STACkIbASE-4 
INTERRUPT~REG  :=  INTERRUPT_FRAME-34 
N  S_P  :=  INTERRUPT  REG-2 

F~C  W  :=  STACK  SEG~SIZE-3SE 


ON  :  = 

OFF  :  = 

RUNNING  := 
READY 

WAITING  := 
NIL  :  = 

INVALID  := 
MONITOR  : 
KERNEL  FCW 
AVAILABLE 
ALLOCATED 


35FFFF 

0 

0 

1 

2 

SFFFF 
35EEEE 
SA900 
:=  355000 
:=  0 
:=  35FF 


H5UG  ENTRY  ! 


TYPE 

MESSAGE  ARRAY  £16  BYTE  J 
ADDRESS  WORD 
VP_IN  DEX  INTEGER 

MSG  INDEX  INTEGER 


SEG  DESC_REG  RECORD 

[ 

BASE  ADDRESS 

ATTRIBUTES 

LIMITS 

] 


BYTE 

BYTE 


MMU 


ARRAY£NR_SDR  S EG_D ESC_REG  ] 


MSG  TABLE  RECORD 


[  MSG 
SENDER 
NEXT_MSG 
FILLER 

] 


MESSAGE 
VP_I NDEX 
MSG_INDEX 
ARRAY  £6,  WORD ] 
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0000 

0210 

0000 

0A00 

OAOA 


VP_TA  BLE  SECOED 
[  DBR  ADDRESS 


PRI  WORD 
STATE  WORD 
ID  LE_FLAG  WORD 
PREEMPT  WORD 


?HYS_PROCESSOR  WORD 


NEXT  READY 
MSG  LIST 
EXT_ID 
FI LLER_1 

] 


VP  VP  INDEX 
MSG_INDEX 
WORD 

ARR AY[  7, 


WORD  ] 


EXTERNAL 

LIST_IN  SERT  PROCEDURE 


GLOBAL 

BOOTSTRAP_ENTRY  LABEL 
3SECTION  ITC  DATA 


VPT  RECORD 

[  LOCK  WORD 

RUNNING_LIST  ARR AY[ NR_CPU  WORD] 

REA DY_LIST  ARR AY[ NR~C?U  WORD] 

FREE_LIST  MSG  INDEX 

V IRT_INT  VEC  ARR AY[ 1 ,  ADDRESS] 

FIL  LER_2~  WORD 

VP  ARRAY  [NR_VP,  VP_T ABLE  ] 

MSG_Q  ARRAY  [NR_VP,~MSG  TABLE] 

] 

EXT_VP_LIST  ARRAY[  NR_AVAIL_VP  WORD] 


SSECTION  M MU  DATA 


MMU  IMAGE  RECORD 

C 

MMU_STRUCTORE  ARRAY[ MAX  DBR  NR  MMU] 

] 

NEXT_AV  AIL_MMU  ARRAY(  MAX_DBR_NR  BYTE] 

PRDS  RECORD 

[PHYS_CPU_ID  WORD 
LOG_C?U_ID  INTEGER 
V  P_NR  WORD 

I DLE_VP  VP_I NDEX  ] 
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ISECTION  ITC_INT_PROC 
INTERNAL 

0000  GETWORK  PROCEDURE 

j  ************* ********* ********* 

*  SWAPS  VIRTUAL  PROCESSORS  * 

*  ON  PHYSICAL  PROCESSOR.  * 

*************  ****************** 


♦ 

PARAMETERS: 

* 

* 

R13: 

LOGICAL  CPU  # 

* 

* 

REGISTER  USE: 

* 

* 

STATUS  REGISTERS 

* 

* 

R  14 

:  DBR  (SIMULATION) 

* 

★ 

R  15 

:  S  T  AC  K_P  0 1  NT  ER 

♦ 

* 

LOCAL  VARIABLES: 

♦ 

* 

R  1 : 

READY  VP  (NEW) 

* 

* 

R2: 

CORRENT_VP  (OLD) 

* 

♦ 

R3 ; 

FLAG  CONTROL  WORD 

* 

* 

R4 : 

ST ACK_SEG  BASE  ADDR 

* 

* 

R5: 

STATUS  REG  BLOCK  ADDR 

* 

♦ 

R6; 

NORMAL~STACK  POINTER 

* 

*******************************  I 

ENTRY 


!  GET 

STACK  BASE  ! 

0000 

31E4 

LD 

R4 ,  R14  (#STACK  SEG*4) 

0002 

0004 

0004 

3445 

LDA 

R5 ,  R4  (#STATUS_REG_ 

BLOCK) 

0006 

00F0 

•  *  * 

SAVE  SP  *  *  ! 

0008 

2F5F 

LD 

<DR5  ,  R  1 5 

!  *  * 

SAVE  FCW  *  *  ! 

000A 

7D32 

LDCTL 

R3,  FCW 

OOOC 

3343 

LD 

R4(#F_C_W),  R3 

000E 

00F2 

BOOTSTRAP 

_E  NTR Y :  !  GLOBAL 

LABEL 

!  GET 

READY  VP  LIST  ! 

0010 

61D1 

LD 

R1r  VPT. READY  LIST(R13) 

0012 

0006* 

SELECT 

_VP : 

DO  ! 

UNTIL  ELGIBLE  READY  VP 

FOUND 

00  14 

4D1 1 

CP  VPT  .  VP .  IDLE  FLAG  (R  1 )  *  #ON 

0016 

0016* 

00  18 

FFFF 

00 1 A 

5E0E 

IF  EQ  !  VP  IS  IDLE  !  THEN 

001C 

0030* 

00  IE 

4D11 

CP 

VPT. VP. PREEMPT (R1) ,  *ON 

0020 

0018* 

0022 

FFFF 

0024 

5E0E 

IF 

EQ  !  PREEMPT  INTERRUPT 

IS  ON 

0026 

002C* 

0028 

5E08 

T7 

Ej 

XIT  FROM  SELECT_VP 

002  A 

003C* 

THEN 
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FI 


002C 

5E08 

ELSE  !  VP  NOT  IDLE  ! 

002E 

0034* 

0030 

5E08 

EXIT  FROM  SELSCT_ VP 

0032 

003C* 

FI 

!  GET  NEXT  READY_VP  i 

0034 

6113 

LD  R3,  VPT. VP. NEXT_READY 

0036 

001C' 

0038 

A131 

LD  R1,  R  3 

003A 

E8EC 

OD 

!  NOTE:  THE  READY_LIST  WILL  NEVER  BE  EMPTY  SINCE 
THE  IDLE  VP,  WHICH  IS  THE  LOWEST  PEI  VP, 

WILL  NEVER  BE  REMOVED  FROM  THE  LIST. 

IT  WILL  RON  ONLY  IF  ALL  OTHER  READY  VP'S  ARE 
IDLING  OR  IF  THERE  ARE  NO  OTHER  VP'S  ON 
THE  READY_LIST.  ONCE  SCHEDULED,  IT 
WILL  RUN  UNTIL  RECEIVING  A  HD  WE  INTERRUPT,  i 

!  NOTE:  R 14  IS  USED  AS  DBR  HERE.  WHEN  MMU 

IS  AVAILABLE  THIS  SERIES  OF  SAVE  AND  LOAD 
INSTRUCTIONS  WILL  BE  REPLACED  BY  SPECIAL  I/O 
INSTRUCTIONS  TO  THE  MMU.  ! 

!  PLACE  NEW  VP  IN  RUNNING  STATE  I 


003C 

4D15 

LD 

VPT. VP. STATE  (R1) ,  ^RUNNING 

003E 

0014* 

0040 

0000 

0042 

6FD 1 

LD 

VPT  .  RUNN ING_LIST  ( R 1 3)  ,  R1 

0044 

0002' 

!  * 

*  SWAP  DBR  *  *  ! 

0046 

61  IE 

LD 

R 1  4  ,  VPT.  VP.  DBR  (R  1) 

0048 

0010' 

!  LOAD  NEW  VP  SP  ! 

004A 

31E4 

LD 

R4  ,  R14  (#STACK_SEG*4) 

0  04C 

0004 

004E 

3445 

LD  A 

R5  ,  R4  (#STATUS_REG_3L0CK) 

0050 

00F0 

0052 

215F 

LD 

R1  5 ,  a)R5 

!  * 

*  LOAD  NEW  FCW  *  *  ! 

0054 

3143 

LD 

R3  ,  R4(#F_C_W) 

0056 

00F2 

0058 

7D3A 

LDCTL  FCW ,  R  3 

005A 

9E08 

RET 

005C 

END  GETWORK 
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005C  ENTER_MSG_LIST  PROCEDURE 

i **************  *********  ********** 

*  INSERTS  POINTER  TO  MESSAGE  * 

*  FROM  CURRENT_VP  TO  SIGNALED_VP* 

*  IN  FIFO  MSG_LIST  * 

********************************* 


* 

REGISTER  USE: 

* 

* 

PARAMETERS: 

* 

♦ 

R8  (R9)  :  MSG  (INPUT) 

* 

♦ 

R  1 : 

SIGNALED_VP  (INPUT) 

* 

* 

R 1  3 : 

LOGIC AL~CPU  NUMBER 

* 

* 

LOCAL 

VARIABLES: 

* 

♦ 

R2: 

CURRENT_V  P 

♦ 

* 

R  3 : 

FIRST_FREE_MSG 

* 

* 

R4  : 

NEXT  FREE  MSG 

* 

* 

R5: 

NEXT  Q  MSG 

♦ 

* 

R6: 

PRESENT  Q  MSG 

* 

********************************* i 

ENTRY 

005C  61D2  LD  R2,  VPT. R UNNING_LIST (R 1 3) 

005E  0002' 


!  GET  FIRST  MSG  FROM  FREE_LIST  ! 
0060  6103  LD  R3,  VPT. FREE  LIST 
0062  000A' 


0064  0303 
0066  FFFF 
0068  5E0E 
006A  0078' 
006C  7601 
006E  006C 
0070  2100 
0072  0004 
0074  5F00 
0076  A900 


l  *  *  *  *  DEBUG  *  m  *  *  l 
CP  R3,  #NIL 

IF  SQ  THEN 

LD  A  R1r  $ 

LD  RO ,  # M_L_0 1  MESSAGE  LIST  OVERFLOii  ! 
CALL  MONITOR 
FI 

!  *  *  *  END  DEBUG  *  *  *  i 


0078  6134  LD  R4,  VPT. MSG_Q. NEXT_MSG (R3) 
007 A  0122' 

007C  6F04  LD  VPT . FREE_LIST,  R4 
0  07E  000A ' 


0080  763 A 
0082  0110* 
0084  2107 
0086  0010 
0088  BA8 1 
008A  07 AO 
008C  6F32 
008E  0120' 


!  INSERT  MESSAGE  LIST  INFORMATION  i 


LD  A 

RIO  r VPT. MS G_Q. MSG (R3) 

LD 

R7 , #SI ZEOF  MESSAGE 

LDIRB 

5>RlO,aR8,R7 

LD  VPT 

.  MSG_Q.  SENDER  (R3)  ,  R2 
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0090 

6115 

LD  R5, 

VPT. VP.MSG_LISZ (£1) 

0092 

00  1 E* 

0094 

0B05 

CP  R5, 

#NIL 

0096 

FFFF 

0098 

5E0E 

IF  EQ 

!  MSG  LIST  IS  EMPTY  i  THEN 

009  A 

00  A4  ' 

!  INSERT  MSG  AT  TOP  OF  LIST  i 

009C 

6F13 

LD  VPT 

. VP.MSG_LIST(R1) ,  £3 

009E 

00  1 E ' 

00A0 

5E08 

ELSE  ! 

INSERT  MSG  IN  LIST  ! 

00A2 

OOBC* 

HSG_Q_SEARCH: 

DO  !  WHILE  NOT  END  OF  LIST  I 

00A4 

0B05 

CP 

R5,  #  NIL 

00A6 

FFFF 

00A8 

5E0E 

IF  EQ 

1  END  OF  LIST  !  THEN 

00  AA 

OOBO* 

OOAC 

5E08 

EXIT 

FROM  MSG_Q_SEARCH 

OOAE 

00  B8 ' 

FI 

!  GET 

NEXT  LINK  ! 

OOBO 

A 156 

LD 

P.6,  E5 

00B2 

6165 

LD 

R5,  VPT.MSG_Q.NEXT_MSG(R6) 

00B4 

0122* 

00B6 

E8F6 

OD 

!  INSERT  MSG  IN  LIST  ! 

00B8 

6F63 

LD 

VPT. MSG_Q.NEXT_MSG (R6) ,  R3 

OOBA 

0122* 

FI 

OOBC 

6F35 

LD 

VPT . MSG_Q. NEXT_MSG (R3) ,  R5 

OOBE 

0122' 

OOCO 

9E08 

RET 

00C2 


2ND  ENTER  MSG  LIST 


341 


00C2 


GET_FIR  ST_MSG  PROCEDURE 

i ** **** ****** * i¥****« ****** ********* 

*  REMOVES  MSG  FROM  MSG_LIST  * 

*  AND  PLACES  ON  FREE  LIST.  * 

*  RETURNS  SENDER'S  MSG  AND  * 

*  VP_ID  * 

*********************************** 

♦REGISTER  USE:  ♦ 

*  PARAMETERS:  * 

*  R8(R9):  MSG  POINTER  (INPUT)  * 


* 

R13: 

LOGICAL  CPU  NUM3ER  (INPUT)  * 

♦ 

HI: 

SENDER  VP  (RETURNED)  ♦ 

* 

LOCAL 

VARIABLES  * 

* 

R2: 

CURRENT_VP  * 

♦ 

R3: 

FIRST_MSG  ♦ 

♦ 

R« : 

NEXT_MSG  * 

* 

R5: 

NEXT~FREE  MSG  * 

* 

R6 : 

PRESENT  FREE  MSG  * 

***********************************  j 

ENTRY 

00C2 

6  1D2 

LD 

R2r  VPT.  RUNNING_LIST  (R  13) 

0  0C4 

0002' 

j 

REMOV 

E  FIRST  MSG  FROM  MSG_LIST  ! 

00C6 

6123 

LD 

R3,  VPT. VP.MSG_LIST(R2) 

00C8 

00  IE' 

i  *  *  *  *  debug  ♦  ♦  ♦  ♦  i 

OOCA 

0B03 

CP  R3,  #NIL 

OOCC 

FFFF 

OOCE 

5E0E 

IF  EQ  THEN 

OODO 

OODE* 

OOD2 

2100 

LD  RO,  #M_L_EM  l  MSG  LIST 

00D4 

0001 

00D6 

7601 

LD A  HI,  $ 

OOD8 

00D6 ' 

OODA 

5F00 

CALL  MONITOR 

OODC 

A900 

FI 

•  *  *  *  END  DEBUG  *  *  *  * 

OODE 

6134 

LD 

R4 ,  VPT. MSG_Q.NEXT_MSG (R3) 

OOEO 

0122* 

00E2 

6F24 

LD 

VPT  .  VP .  MSG_LIST  (22)  ,  R4 

00E4 

00  IE* 

!  INSERT  MESSAGE  IN  FREE_LIST 

00E6 

6105 

LD 

R5,  VPT. FREE_LISI 

00E8 

000  A ' 

OOEA 

0B05 

CP 

H5,  #NIL 

0  0  EC 

FFFF 

00  EE 

5E0E 

IF 

2Q 

!  FREE_LIST  IS  EMPTY  1  THEN 

OOFO 

0100* 

; 

INSERT  AT  TOP  OF  LIST  ! 

00F2 

6F03 

L 

D 

VPT . FREE_LIST ,  S3 

00F4 

000  A ' 
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00F6 

4D35 

LD 

VPT . MSG_Q. NEXT_MSG (R3) , 

#  NIL 

00F8 

0122* 

OOFA 

FFFF 

OOFC 

5E08 

ELSE  l 

INSERT  IN  LIST  ! 

0  OFE 

011C' 

FBEE_Q  SEARCH: 

DO 

0100 

0B05 

CP 

R5,  #NIL 

0102 

FFFF 

0104 

5E0E 

IF  SQ 

!  END  OF  LIST  !  THEN 

0106 

010C' 

0108 

5E08 

EXIT 

FROM  FREE_Q_SEARCH 

010A 

0114* 

FI 

!  GET 

NEXT  MSG  ! 

010C 

A156 

LD 

R6,  R5 

0  1 0E 

6165 

LD 

R5,  VPT. MSG  Q . NEXT  MSG  (R6) 

01  10 

0122' 

0112 

E8F6 

OD 

!  INSERT 

IN  LIST  ! 

0114 

6F6  3 

LD 

VPT . MSG_Q. NEXT.MSG (R6)  , 

R3 

0  1  16 

0122' 

0118 

6F35 

LD 

VPT . MSG_Q. NEXT_MSG (R3) , 

R5 

01  1A 

0122* 

FI 

!  GET  MESSAGE  INFORMATION: 

(RETURNS  R1  :  SENDING_VP)  ! 

01 1C 

6131 

LD 

R1,  VPT.  MSG_Q.  SENDER  (S3) 

01  IE 

0120* 

0120 

763A 

LDA 

RIO,  VPT.  MSG_Q.  MSG  (R3) 

0122 

0110' 

0124 

2107 

LD 

R7,#SIZEOF  MESSAGE 

0  126 

0010 

0128 

BAA1 

LDIRB 

a)R8,a)RlO,R7 

0  12A 

0780 

012C 

9E08 

RET 

0122 

END  GET_FIRST_MSG 
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!  *  *  INNER  TRAFFIC  CONTROL  ENTRY  POINTS  *  *  ! 


0000 


0000 

0002 


0004 

0006 

0008 

000A 


!  NOTE:  ALL  INTERRUPTS  MUST  BE  MASKED  WHENEVER 
THE  VPT  IS  LOCKED.  THIS  IS  TO  PREVENT  AN 
EMBRACE  FROM  OCCURRING  SHOULD  AN  INTERRUPT 
OCCUR  WHILE  THE  VPT  IS  LOCKED.  ! 

GLOBAL 

$  SECTION  ITC_GLB_PROC 

PREEMPT_RET  LABEL 
KERNEL_EXIT  LABEL 

CREATE_I NT_VEC  PROCEDURE 

»  ******************************** 

*  CREATES  ENTRY  IN  VIRTUAL  INT-* 

*  ERRUPT  VECTOR  WITH  ADDRESS  * 

*  OF  THE  VIRTUAL  INTERRUPT  HAN-* 

*  DLER .  * 

******************************** 

*  PARAMETERS:  * 

*  R1:  VIRTUAL  INTERRUPT  #  * 

*  R2 :  INTERRUPT  HANDLER  ADDR  * 

******************************** i 

ENTRY 


!  COMPUTE  OFFSET  IN  VIRTUAL 
INTERRUPT  VECTOR  ! 


1900 

0002 

MULT 

RRO,  tSIZEOF 

ADDRESS 

!  SAVE 

ADDRESS  OF  VIRTUAL  INTERRUPT 

HANDLER  IN  INTERRUPT 

VECTOR  ! 

6F12 

LD 

VPT  .  VIRT_I  NT. 

_VEC (R 1 )  ,  R2 

000C' 

9E08 

RET 

END  CREATE  INT  VEC 
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OOOA 


OOOA  7601 
OOOC  0000* 


OOOE  8101 
0010  9E08 
0012 


GET_DBR_ADDR  PROCEDURE 

f  * ****************  ** ******** ***** 

*  CALCULATES  D3R  ADDRESS  FROM  * 

*  DBR  NUMBER  * 

**************  ****************** 


*  REGISTER  USE:  * 

*  PARAMETERS:  * 

*  RO:  DBR  *  * 

*  RETURNS:  * 

*  R 1 :  DBR  ADDRESS  * 


******************************** i 

ENTRY 

•  GET  BASE  ADDRESS  OF  MMU  IMAGE  ! 
LDA  HI,  MMU_IM AGE 


•  ADD  DBR  HANDLE  (OFFSET)  TO  MMU  BASE 
ADDRESS  TO  OBTAIN  DBR  ADDRESS  ! 

ADD  R1,  RO 

RET 

END  GET  DBR  ADDR 
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0012  ALLOCATE_MMU  PEOCEDUR  E 

; *** ***************************** 

*  ALLOCATES  NEXT  AVAILABLE  MMU  * 

*  IMAGE  AND  CREATES  PHDS  ENTRY  * 

******************************** 


* 

REGISTER  USE: 

* 

* 

RETURNS: 

* 

¥ 

RO: 

DBR  * 

¥ 

* 

LOCAL 

VARIABLES: 

* 

♦ 

R  1 : 

SEGMENT  # 

* 

* 

R2  : 

PRDS  ADDRESS 

* 

¥ 

R3: 

PRDS  ATTRIBUTES 

¥ 

¥ 

R4 : 

PRDS  LIMITS 

* 

******************************** i 


ENTRY 

!  GET  NEXT  AVAILABLE  DBR  #  ! 

0012  8D08  CLR  RO 

0014  8D18  CLR  R1 

!  NOTE:  THE  FOLLOWING  IS  A  SAFE  SEQUENCE 
AS  NEXT_AVAIL_MMU  AND  MMU  ARE  CPU  LOCAL! 
GET_DB  R: 

DO 

0016  4C11  CPB  NEXT_AVAIL_MMU (R 1 >  ,  # A  VAIL ABLE 

0018  0A00' 

0 0 1  A  0000 


001C  5E0E 
0 0 1 E  002E' 
0020  4C15 
0022  0A00 1 
0024  FFFF 
0026  5E08 
0028  004 A1 
002A  5E08 
002C  0048' 
0  02 E  A910 
0030  0100 
0032  0100 


IF  EQ  !  MHO  ENTRY  IS  AVAILABLE! 

THEN 

LDB  NEXT_AVAIL_MMU (HI)  ,  # ALLOCATED 
EXIT  FROM  GET_DBR 

ELSE  SCURRENT  ENTRY  IS  ALLOCATED! 

INC  R 1 ,  #1 

ADD  RO,  #SIZEOF  MMU 


i  *  *  *  *  DEBUG  *  *  *  *  ! 
0034  0B0 1  CP  R 1 ,  #MAX_DBR_NR 

0036  000 A 

0038  5E0E  IF  EQ  THEN 

003A  0048' 


003C 

2100 

LD 

003E 

0007 

0040 

7601 

LDA 

0042 

0040* 

0044 

5F00 

CALL 

0046 

A900 

FI 

>  *  *  * 

FI 

0048 

E8E6 

OD 

RO,  #M_U  ! MMU  UNAVAILABLE 
HI,  $ 

MONITOR 

END  DEBUG  *  *  *  « 
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0  04  A 

2101 

LD 

R1, 

#PRDS_SEG 

i  SEGMENT  NO.  ! 

0  04C 

0000 

004E 

7602 

LDA 

92, 

PRDS 

!  PRDS  ADDR  ! 

0050 

0A0A' 

0052 

2103 

LD 

R3, 

#1  !  READ 

ATTR  1 

0054 

000  1 

0056 

2104 

LD 

B«# 

#  (  (SIZEOF 

PRDS)  -  1) /256 

0058 

0000 

!  PRDS 

LIMITS 

t 

• 

!  CREATE 

PRDS 

ENTRY  IN  MMU  IMAGE  ! 

005A 

5F00 

CALL 

OPD ATE_MMO_IMAGE  !(R1:  SEGMENT  # 

005C 

0060* 

R2:  SEG  ADDRESS 
R3:  ATTRIBUTES 
R4 :  SEG  LIMITS) 

005E 

SE08 

RET 

0060  END  ALLOCATE_MMU 
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0060  UPD ATE_M  MU_IMAGE  PROCEDURE 

i ******************************** 

*  CREATES  SEGMENT  DESCRIPTOR  * 

*  ENTRY  IN  MMU  IMAGE  * 

******************************** 


* 

REGISTER  USE: 

* 

♦ 

PARAMETERS: 

* 

* 

RO  : 

DBR  # 

♦ 

* 

R1: 

SEGMENT 

* 

* 

* 

R2 : 

SEGMENT 

ADDRESS 

* 

* 

R3: 

SEGMENT 

ATTRIBUTES 

* 

* 

R4 : 

SEGMENT 

LIMITS 

* 

* 

LOCAL 

VARIABLES: 

* 

* 

RIO: 

MMU  BASE  ADDRESS 

* 

* 

R  1 3: 

OFFSET 

VARIABLE 

* 

******************************** t 

ENTRY 


0060 

0062 

210A 

0000* 

LD 

RIO,  #MMU_IMAGE  !  MMU  BASE  ADDRESS  ! 

0064 

810A 

ADD 

RIO,  RO 

0066 

0068 

210D 

0004 

LD 

R 13 ,  tSIZEOF  SEG_DESC_REG 

006A 

99  1C 

MULT 

RR12,  R 1  !  COMPUTE  SEG  DESC  OFFSET  ! 

006C 

8  1  DA 

ADD  RIO,  R13  1  ADD  OFFSET  TO  BASE  ADDRESS! 

!  INSERT  DESCRIPTOR  DATA  ! 

006E 

2FA2 

LD 

3R10,  R2 

0070 

A9  A 1 

INC 

RIO,  #2 

0072 

0DA8 

CLR 

3R10 

0074 

2EAC 

LDB 

a»R10,  RL4 

0076 

A9A0 

INC 

RIO,  #1 

0078 

20  AC 

LDB 

RL4 ,  9R10 

007  A 
007C 

OAOB 

0808 

CPB 

RL3,  #*(2)00001000  1  EXECUTE  ! 

007E 

0080 

5E0E 

008A' 

IF 

EQ  THEN 

0082 

0084 

060C 

F7F7 

AND B  RL4 ,  #*(2)11110111  !  EXECUTE  MASK 

0086 

0088 

5E08 

008E' 

ELSE 

008A 

008C 

060C 

FEFE 

FI 

ANDB  RL4 ,  #*(2)11111110  !  READ  MASK  ! 

008E 

84  BC 

ORB 

RL4 ,  RL3 

0090 

2EAC 

LDB 

SR  10,  RL4 

0092 

9E08 

RET 

0094 

END  UPDATE  MMU  IMAGE 
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0094  WAIT  PROCEDURE 

j  **********************************„ 


*  INTRA_KERNEL  SYNC/COM  PRIMATIVE  * 


*  INVOKED  BY  KERNEL  PROCESSES  * 

******** ** * * *******  * * * ** * ** * *** * * * * 

*  PARAMETERS  * 

*  R8(R9):  MSG  POINTER  (INPUT)  * 

*  R1:  SENDING_VP  (RETURN)  * 

*  GLOBAL  VARIABLES  * 

*  R14:  DBR  (PARAM  TO  GETWORK)  * 

*  LOCAL  VARIABLES  * 

*  R2:  CURRENT_VP  (RUNNING)  * 

*  R3:  N EXT_READY  VP  * 

*  R4 :  LOCK_ADDRESS  * 

*  R13:  LOGICAL  CPU  NUMBER  * 

***********************************  I 


ENTRY 

!  MASK  INTERRUPTS  ! 


0094 

7C01 

DI  VI 

!  LOCK  VPT  ! 

0096 

7604 

LDA 

R4  t  VPT. LOCK 

0098 

0000* 

009  A 

5F00 

CALL 

SPI N_LOCK  I  (R4: -.VPT.  LOCK)  1 

009C 

0282' 

!  NOTE:  RETURNS  WHEN  VPT  IS  LOCKED  BY  THIS 

!  GET  CPU 

NUMBER  I 

009E 

5F00 

CALL 

GET_CPU_NO  ! RETURNS ; 

00  AO 

02C8 ' 

R1; CPU  # 

R2:  #  VP'S! 

00A2 

A1  ID 

LD 

R13  ,  R  1 

00A4 

6  1D2 

LD 

R2,  VPT.RUNNING_LIST  (R  13) 

00A6 

0002' 

00A8 

6123 

LD 

R3,  VPT. VP .NEXT_READY_VP (R2) 

00  AA 

001C' 

00  AC 

4D2  1 

CP 

VPT . VP . MSG_LIST (R2) ,  #NIL 

i 


OOAE  00 1 E' 
OOBC  FFFF 
00B2  5E0E 
00B4  OOEA 1 


IF  EQ  !  CURRENT  VP'S  MSG  LIST  IS  EMPTY  I  THEN 


00B6  0B03 
00B8  FFFF 
OOBA  5E0E 
OOBC  OOCA' 
OOBE  2100 
00C0  0003 
00C2  7601 
00C4  00C2 ' 
00C6  5F00 
00C8  A900 


REMOVE  CUSRENT_VP  FROM  READY.LIST  i 
i  *  *  *  *  DEBUG  ***** 

CP  R3 ,  #  NIL 

IF  EQ  THEN 

LD  RO,  #R_L_E  !  READY  LIST  EMPTY 
LDA  R1,  $ 

CALL  MONITOR 
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FI 

!  *  *  *  END  DEBUG  *  *  *  ! 


OOCA 

OOCC 

OOCE 

OODO 

00D2 


OOD4 

00D6 

00D8 

OODA 

OODC 

OODE 

OOEO 

00E2 

00E4 


00E6 

00E8 


OOEA 
0  OEC 


OOEE 

OOFO 

00F2 


00F4 

00F6 


6FD3 

0006’ 

4D25 

001C’ 

FFFF 


LD  VPT  .  RE  AD  Y_LI  ST  (R  1 3)  ,  H3 

LD  VPT  .  VP  .  NEXT_READY_VP  (R2)  ,  #NIL 


4D25 
00  14’ 
0002 

612E 

0010' 

93F8 

93FD 

5F00 

0000' 


97FD 

97F8 


5F00 
00C2  ’ 


4D08 

0000* 

7C05 


I  PUT  IT  IN  WAITING  STATE  I 
LD  VPT.VP.STATE(B2) ,  #WAITING 


!  SET  DBR  ! 

LD  R14,  VPT.  VP.  DBR(R2) 

!  SCHEDULE  FIRST  ELGIBLE  READY  VP  ! 

PUSH  dR15,R8 

!  SAVE  LOGICAL  CPU  #  ! 

PUSH  3R15,  R 1 3 

CALL  GETWORK  !R13:CPU  # 

R 1 4 :DBR ! 

!  RESTORE  CPU  *  ! 

POP  R13,  5>R15 

POP  R8,3B15 

FI 

!  GET  FIRST  MSG  ON  CURRENT  VP'S  MSG  LIST  I 
CALL  GET_FIRST_MSG  I  COPIES  MSG  IN  MSG  ARRAY  1 

I  R 1 3:  LOGICAL  CPU  *  I 
! RETURNS  R1:SENDER_VP  ! 

I  UNLOCK  VPT  ! 

CLR  VPT. LOCK 

!  UNMASK  VECTORED  INTERRUPTS  ! 

El  VI 


!  RETURN:  R1:SENDER_VP  I 
9E08  RET 

END  WAIT 


350 


00F6 


SIGNAL  PROCEDURE 

j  **************  ******************* **# 

*  I NTRA_KERNEL  SYNC  /COM  PRIMATIVE  * 

*  INVOKED  BY  KERNEL  PROCESSES  * 

************************************ 

*  REGISTER  USE:  * 

*  PARAMETERS:  * 

*  R8(R9):  MSG  POINTER  (INPUT)  * 

*  R1:  SIGNALED  VP  ID  (INPUT)  * 

*  GLOBAL  VARIABLES  ~  * 

*  R13:  CPU  #  (PARAd  TO  GETWORK)  * 

*  R14:  DBR  (PARAM  TO  GETWORK)  * 

*  LOCAL  VARIABLES:  * 

*  R 1 :  SIGNALED  VP  * 

*  R2:  CURRENT_V  P  * 

*  R4:  VPT .  LOCK  ADDRESS  * 

************************************ , 
ENTRY 

!  SAVE  VP  ID  ! 


00F6 

93F1 

PUSH 

3R15, 

R1 

!  MASK 

INTERRUPTS  ! 

00F8 

7C01 

DI 

VI 

!  LOCK 

VPT  ! 

OOFA 

7604 

LDA 

R4, 

VPT. LOCK 

OOFC 

0000» 

00  FE 

5F00 

CALL 

SPIN 

.LOCK  !  (R4:-VPT. LOCK) 

1 

0  100 

0282* 

!  NOTE: 

RETURNS 

WHEN  VPT  IS  LOCKED  BY  THIS 

!  GET 

LOGICAL 

CPU  #  ! 

0102 

5F00 

CALL 

GET_ 

CPU_NO  ! RETURNS: 

0104 

02C8  * 

R1.-CPU  # 

R2:#  VP'Si 

0106 

A 1  ID 

LD 

R13, 

R  1 

!  RESTORE  VP  ID  ! 

0108 

97F1 

POP 

si. 

alR  15 

l  PLACE  MSG  IN 

SIGNALED_VP • S  MS3_LIST 

1 

0  10  A 

5F00 

CALL  ENTER  MSG 

LIST  !  (R8 : MSG  POINTER 

010C 

005C* 

R 1 : SIGN ALE D_ VP 

R 1 3: LOGICAL  CPU 

#) 

0  10E 

4D1  1 

CP 

VPT. 

VP.  STATE  (R1)  ,  AWAITING 

0110 

0014' 

01  12 

0002 

0114 

5E0E 

IF  EQ 

!  SIGNALED_VP  IS  WAITING  !  THEN 

0  1  16 

0148' 

I  WAKE  IT  UP 

AND  MAKE  IT  READY  ! 

01  18 

A112 

LD 

R2 , 

R 1 

01  1 A 

76D3 

LDA 

R3  f 

VPT. READ Y_LISI (R13) 

0  1  1C 

0006* 

01  IE 

7604 

LDA 

54, 

VPT. VP.NEXT_READY_VP 

0120 

001C* 
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0122 

7605 

LDA 

R5,  VPT.VP.PRI 

0124 

0012' 

0  126 

7606 

LDA 

R6  ,  VPT.  VP. STATE 

0123 

0014' 

0  12A 

2107 

LD 

R7,  #READY 

012C 

0001 

!  SAVE 

LOGICAL  CPU  #  ! 

012E 

93FD 

POSH 

a)R1 5,  R13 

0  130 

5F00 

CALL 

LIST_INSERT  ! R2 

0132 

0000* 

R3:  LIST_PTR  ADDS 
S4;  NEXI_OB J_PTR 
R5:  PRIORITY_PTR 
R6:  STATE  PTR 
R7:  STATE  ! 

I  RESTORE  LOGICAL  CPU  #  ! 


0  134 

97FD 

POP 

R  1  3  ,  a)R  1  5 

!  PUT  CURRENT  VP 

IN  READY_STATE  1 

0136 

61D2 

LD 

R2,  VPT 

.  RUNNING_LIST  (R  13) 

0138 

0002* 

0  13A 

4D25 

LD 

VPT. VP. 

STATE  (R2),  #READI 

013C 

0014’ 

01  3E 

0001 

!  SET  DBR  ! 

0140 

612E 

LD 

R14,  VPT. VP.DBR(R2) 

0142 

0010* 

!  SCHEDULE  FIRST 

ELGIBLE  READY  VP  I 

0144 

5F00 

CALL 

GETWORK 

! R  13 : LOGICAL  CPU 

0146 

0000* 

FI 

R  14. -DBR  ! 

!  UNLOCK 

VPT  ! 

0148 

4D08 

CLR  VPT. 

LOCK 

0  1 4  A 

0000* 

!  ONMASK 

VECTORED 

INTERRUPTS  ! 

0  14C 

7C05 

El  VI 

014E 

9E08 

RET 

0150 

END  SIGNAL 
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SET_PREE  MPT  PROCEDURE 

I  **************************** 

*  SETS  PREEMPT  INTERRUPT  ON* 

*  TARGET_VP.  CALLED  BY  TC_  * 

*  ADVANCE.  ~  * 

************** ************** 


*  REGISTER  USE:  * 

*  PARAMETERS:  * 

*  R1:TARGET_VP  ID  (INPUT)  * 

*  LOCAL  VARIABLES  * 

*  R1:  VP  INDEX  * 


******************* ********* i 

ENTRY 

!  NOTE:  DESIGNED  AS  SAFE  SEQUENCE  SO  VPT  NEED 
NOT  BE  LOCKED.  ! 


!  CONVERT  VP_ID  TO  VP_INDEX  ! 

0150  6112  LD  R2,  EXT  VP_LIST(R1) 

0152  0210* 

1  TURN  ON  TGT_VP  PREEMPT  FLAG  i 
0154  4D25  LD  VPT .  VP .  PREEMPT  (R2)  ,  #ON 

0156  0018* 

0158  FFFF 

I  **  IF  TARGET  VP  NOT  LOCAL 

(  NOT  BOUND  TO  THIS  CPU  ) 

[IE,  IF  «CPU_SEG»C PU_IDOVPT.VP.PHYS_CPU(R1)  ] 
THEN  SEND  HARDWARE  PREEMPT  INTERRUPT  TO 
VPT  .  V P  .CPU  ( R  1)  .  **  ! 


015A  9E08  RET 

015C  END  SET  PREEMPT 
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IDLE  PROCEDURE 

»  ************************* 

*  LOADS  IDLE  DBR  ON  * 

*  CURRENT  VP.  CALLED  BY  * 

*  TC_GETWORK.  * 

************************* 


*  REGISTER  USE 

*  GLOBAL  VARIABLE 

*  R13:  LOG  CPU  # 


* 

* 

* 


* 

R 14: 

DBR 

* 

* 

LOCAL 

VARIABLES: 

* 

* 

R2: 

CURRENT_VP 

* 

* 

R3: 

TEMP  VAR 

* 

♦ 

R4 : 

VPT. LOCK  ADDR 

* 

* 

R5: 

TEMP 

* 

************************* | 

ENTRY 

GET  LOGICAL  CPU  #  ! 


0  15C 

5F00 

CALL 

GET_CPU_NO  .'RETURNS: 

!  LOAD 

IDLE  DBR  ON  CURRENT  VP  ! 

0174 

6103 

LD 

R3,  PRDS . IDLE_VP 

0176 

0A  10 ' 

0178 

6135 

LD 

R5,  VPT. VP. DBR  (R3) 

017A 

0010' 

017C 

6F25 

LD 

VPT.  VP.  DBR  (R2)  ,  R5 

0  17E 

0010' 

»  TURN 

ON  CURRENT  VP'S  IDLE  FLAG  J 

0180 

4D25 

LD 

VPT  .  VP .  IDLE_FLAG  (R2)  ,  #ON 

0  182 

0016' 

0184 

FFFF 

!  SET 

VP  TO  READY  STATE  J 

0186 

4D25 

LD 

VPT.  VP.  STATE  (R2)  ,  #READY 

0188 

0014* 

0  18A 

0001 

!  SCHEDULE  FIRST  ELIGIBLE  READY  VP 

0  13C 

5F00 

CALL 

GETWORK  ! R 13 : LOGICAL  CPU  # 

018E 

0000' 

R  14  :DBR  .' 

•  UNLOCK  VPT  ! 

0  190 

4D0  8 

CLR  VPT. LOCK 

0192 

0000' 

!  UNMASK  VECTORED  INTERRUPTS  ! 

0194 

7C05 

El 

VI 

0196  9E0 8 
0198 


RET 

END  IDLE 
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0198 


0198 

93F 1 

019A 

7C01 

0  19C 

7604 

019E 

0000' 

01  AO 

5F00 

0  1A2 

0282' 

0  1A4 

5F00 

0  1A6 

02C8 ' 

0 

1A8 

A 1  ID 

0 

1 A  A 

61D2 

0 

1  AC 

0002' 

0 

1  AE 

4D2  1 

0 

1  30 

001E* 

0 

1B2 

FFFF 

0 

1B4 

5E06 

0 

1B6 

01C4 ' 

0 

1B8 

2100 

0 

1  BA 

0005 

0 

1 BC 

7601 

0 

1  BE 

0 1BC* 

0 

ICO 

5F00 

0 

1C2 

A900 

01C4 

612E 

01C6 

0010 

SWAP_VDBR  PROCEDURE 

I  ************************* 

*  LOADS  NEW  DBR  ON  * 

*  CURRENT  VP.  CALLED  BY  * 

*  TC_GETWORK.  * 

************************* 

*  REGISTER  USE  * 

*  PARAMETERS  * 

*  R 1  :  NEW_DBfi  (INPUT)  * 

*  GLOBAL  VARIABLES  * 

*  R 13:  LOGICAL  CPU  *  * 

*  R14:  DBR  * 

*  LOCAL  VARIABLES  * 

*  R2 :  CURRENT_V  P  * 

*  R4 :  V PT . LOCK  ADDR  * 

************************* i 

ENTRY 

!  SAVE  NEW  DBR  i 
POSH  3E15,  R 1 

!  MASK  INTERRUPTS  ! 

DI  VI 
!  LOCK  VPT  ! 

LDA  R4,  VPT. LOCK 

CALL  SPIH_LOCK  !  (R4 :  VPT .  LOCK)  ! 

!  NOTE:  RETURNS  WHEN  VPT  IS  LOCKED  BY  THIS  VP. 
!  GET  CPU  *  ! 

CALL  GET_CPU_NO  'RETURNS: 

HI:  CPU  # 

R2: t  VP'SI 

LD  R13,  R 1 

!  GET  CURRENT  VP  I 

LD  R2 ,  VPT. RUNNING_LIST (R 13) 

!  *  *  *  DEBUG  *  *  *  J 

CP  VPT. VP. MSG_LIST (R2)  ,  #NIL 


IF  NE  I  MSG  WAITING  !  THEN 
LD  HO,  #S_N_A  J  SWAP  NOT  ALLOWED 
LDA  R  1 ,  £  I  PCI 
CALL  MONITOR 
FI 

!  *  *  END  DEBUG  *  *  I 
t  SET  DBR  I 

LD  R14  ,  VPT.VP.  DBR(R2) 

•  RESTORE  NEW  DBR  ! 
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0  1C8 

97F0 

POP 

RO,  a)R  1  5 

0  1  CA 

5F00 

CALL 

GET_DBR_ADDR  !  (RO:  DBR 

0  ICC 

000  A ' 

RETURNS 
(HI:  DBR 

!  LOAD 

NEW  DBR  ON  CURRENT  VP  ! 

0  1 CE 

6F2 1 

LD 

VPT.  VP.  DBR  (R2)  ,  R1 

0  IDO 

0010' 

!  TORN 

OFF  IDLE  FLAG  ! 

01D2 

4D25 

LD 

VPT.  VP.IDLE_FLAG  (R2)  ,  #OFF 

01D4 

0016' 

0  1D6 

0000 

!  SET 

VP  TO  READY  STATE  ! 

01D8 

4D25 

LD 

VPT.  VP.  STATE  (R2)  ,  #READY 

0  IDA 

0014* 

01  DC 

0001 

!  SCHEDULE  FIRST  ELGIBLE  READY  VP  ! 

0  1  DE 

5F00 

CALL 

GETWORK  ! R 13 : LOGICAL  CPU  # 

01E0 

0000' 

R 14 :DBR  ! 

!  UNLOCK  VPT  ! 

0  1E2 

4D08 

CLR  VPT. LOCK 

01E4 

0000' 

!  UNMASK  VECTORED  INTERRUPTS  ! 

01E6 

7C05 

El 

VI 

0  1E8 

9E08 

RET 

0 1  EA 

END  SWAP 

VDBR 
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0 1 EA  PHY  S_PREEMPT_H  ANDLER  PBOCEDUEE 

•  ******************************** 

*  HARDWARE  PREEMPT  INTERRUPT  * 

*  HANDLER.  ALSO  TESTS  FOR  * 

*  VIRTUAL  PREEMPT  INTERRUPT  * 

*  FLAG  AND  INVOKES  INTERRUPT  * 

*  HANDLER  IF  FLAG  IS  SET.  * 

*  INVOKED  UPON  EVERY  EXIT  FROM  * 

*  KERNEL.  KERNEL  FCW  MASKS  * 

*  NVI  INTERRUPTS  TO  PREVENT  * 

*  SIMULTANEOUS  PREEMPT  INTERR.  * 

*  HANDLING.  * 

******************************** 

*  REGISTER  USE  * 

*  LOCAL  VARIABLES  * 

*  R1 :  PREEMPT_INT_FLAG  * 

*  R2 :  CURRENT_VP  * 

*  GLOBAL  VARIABLES  * 

*  R1 3 : LOGICAL  CPU  #  * 

*  R 1 4 ; DBR  * 


**************  ******************* 


ENTRY 

!  *  *  PREEMPT  HANDLER  *  *  ! 


!  SAVE  ALL  REGISTERS  I 
0 1 EA  030F  SUB  R15,  #32 

0 1  EC  0020 

0 1  EE  1CF9  LDM  a)R15,  Rl,  #16 

0 1F0  0 10F 


01F2  7D67 
01F4  93F6 

01F6  5F00 
01F8  02C8' 


0 1 F A  A11D 

0 1 FC  7C01 

0 1 FE  7604 
0200  0000' 
0202  5F00 
0204  0282' 


0206  6 1D2 
0208  0002* 
020A  612E 
0 20C  0010' 


!  SAVE  NORMAL  STACK  POINTER  (NSP) 
LDCTL  R6 ,  NSP 

PUSH  3R15,  R6 

!  GET  CPU  #  ! 

CALL  GET_CPU_NO  ! RETURNS: 

Rl:  CPU  # 
r2 : #  VP‘Si 

LD  S13,  Rl 

!  MASK  INTERRUPTS  ! 

DI  VI 
!  LOCK  VPT  ! 

LD A  R4f  VPT. LOCK 

CALL  S  PIN_LOCK 

IRETURNS  WHEN  VPT  IS  LOCKED! 

!  SET  DBR  ! 

LD  R2,  VPT.RUNNING_LIST(R1  3) 

LD  R 1 4  ,  VPT.  VP. DBR  (R2) 
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!  PUT  CURRENT  PROCESS  IN  READY  STATE  ! 


020E 

4D25 

LD 

VPT. VP. 

STATE  (R2)  , 

#READ Y 

0210 

0014* 

0212 

0001 

0214 

5F00 

CALL 

GETWORK 

!R 13: LOG 

CPU  * 

0216 

0000' 

PREEMPT. 

RET: 

R 14 : DBR 

« 

• 

!  UNLOCK  VPT  I 

0218 

4D08 

CLR 

VPT. LOCK 

02  1 A 

0000* 

!  UNMASK  VECTORED  INTERRUPTS  ! 

02 1C  7C05  El  VI 

KERN  EL_EX IT: 

!  ***  UNMASK  VIRTUAL  PREEMPTS  ***  I 
i  **  NOTE:  SAFE  SEQUENCE  AND  DOES  NOT  REQUIRE 
VPT  TO  BE  LOCKED.  **  I 

!  GET  CURRENT  VP  ! 


02  IE 

6 10D 

LD 

R 1 3 ,  PRDS. LOG_CPU_ID 

0220 

OAOC* 

0222 

61D2 

LD 

R2, 

VPT .  RUNNING_LIS  T  (R13) 

0224 

0002* 

j 

TEST 

PREEMPT  INTERRUPT  FLAG  ! 

0226 

4D21 

CP 

VPT.  VP. PREEMPT  (R2)  ,  #ON 

0228 

0018' 

022A 

FFFF 

0  22C 

5E0E 

IF 

SQ 

!  PREEMPT  FLAG  IS  ON  !  THEN 

0  22E 

0240' 

!  RESET  PREEMPT  FLAG  ! 

0230 

4D25 

LD 

VPT.  VP. PREEMPT  (R2)  ,  #OFF 

0232 

0018* 

0234 

0000 

I  SIMULATE  VIRTUAL  PREEMPT  INTERR 

0236 

2101 

LD 

R 1 ,  #0 

0238 

0000 

0  23A 

6112 

LD 

R2 ,  VPT. VIRT_I NT_VEC (R 1 ) 

0  23C 

000C' 

0  23E 

1E28 

JP 

SR  2 

! NOTE:  THIS  JUMP  TO  IRAFFIC_CQNTRQL 
IS  USED  ONLY  IN  THE  CASE  OF  A  PREEMPT  INTERRUPT, 
AND  SIMULATES  A  HARDWARE  INTERRUPT.  **  ! 


«  ***  SND  virtual  PREEMPT  HANDLER  ***  ! 
FI 


!  NOTE:  SINCE  A  HDWE  INTERRUPT  DOES  NOT  EXIT 
THROUGH  THE  GATE,  THOSE  FUNCTIONS  PROVIDED 
BY  A  GATE  EXIT  TO  HANDLE  PREEMPTS  MUST  BE 
PROVIDED  HERE  ALSO.  ! 
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!  RESTORE  NSP  ! 

0240 

97F6 

POP  R6  , 

5R1  5 

0242 

7D6F 

LDCTL 

NSP,  R6 

!  RESTORE  ALL  REGSTERS 

0244 

1CF  1 

LDM 

R 1  ,  a)R  15  ,  #16 

0246 

01  OF 

0248 

010F 

ADD 

R15,  #32 

024A  0020 

!  EXECUTE  HARDWARE  INTERRUPT  RETURN 
0 24C  7B00  IRET 

0  24E  END  PH IS _P R E EM PT_ HANDLER 
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0  24E  R  UN  NI NG_  VP  PROCEDURE 

********************************** 

*  CALLED  BY  TRAFFIC  CONTROL.  * 

*  RETURNS  VP_ID.  RESULT  IS  VALID* 

*  ONLY  WHILE  APT  IS  LOCKED.  * 

******************************* *  * 


*  REGISTER  USE  * 

*  PARAMETERS  * 

*  R 1 :  EXT_VP_ID  (RETURNED)  * 

*  R3:  LOG  CPU  #  (RETURNED)  * 

*  LOCAL  VARIABLES  * 

*  R2:  VP  INDEX  * 


*********************************  » 

ENTRY 

!  MASK  INTERRUPTS  ! 


0  24  E 

7C01 

DI  VI 

I  LOCK  VPT  ! 

0250 

7604 

LDA 

R4,  VPT. LOCK 

0252 

0000' 

0254 

5F00 

CALL 

SPIN_LOCK  !  (R4: -VPT. LOCK)  ! 

0256 

0282* 

!  NOTE:  RETURNS  WHEN  VPT  IS  LOCKED  BY  THIS 
!  GET  LOGICAL  CPU  *  ! 

0258 

5F00 

CALL 

GET_CPU_NO  ! RETURNS: 

025  A 

02C8 ' 

R1:  CPU  # 

R2:  #  VP’S! 

025C 

A113 

LD 

R3 ,  R1 

025E 

6132 

LD 

R2,  VPT.  RUNNING_LIST  ( R 3) 

0260 

0002* 

!  CONVERT 

VP_INDEX  TO  VP_ID  ! 

0262 

6121 

LD 

Rlr  VPT. VP.EXT_ID (R2) 

0264 

0020* 

•  *  *  *  DEBUG  *  *  *  1 

0266 

0B0  1 

CP  HI,  #NIL 

0268 

FFFF 

026A 

5E0E 

IF  EQ  !  KERNEL  PROC  !  THEN 

026C 

027A* 

026E 

2100 

LD  RO,  #V_I_E  1  VP  INDEX  ERROR 

0270 

0006 

0272 

7601 

LDA  81,  $ 

0274 

0272' 

0276 

5F00 

CALL  MONITOR 

0278 

A900 

FI 

!  *  *  END  DEBUG  *  *  ! 

1  UNLOCK 

VPT  ! 

027A 

4D08 

CLR 

VPT. LOCK 

027C 

0000* 

!  UNMASK 

VECTORED  INTERRUPTS  ! 

027E 

7C05 

El  VI 

0280 

9E08 

RET 

0282 

END  RUNNING 

VP 
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0282 


SPIN_LOCK  PHOCEDOBE 

I  ************************* 

*  USES  SPIN_LOCK  MECH.  * 

*  LOCKS  UNLOCKED  DATA  * 

*  STRUCTURE  (POINTED  TO  * 

*  BY  INPUT  PARAMETER) .  * 

************************* 

♦REGISTER  USE  ♦ 

*  PARAMETERS  * 

*  R4  :  LOCK  ADDR  (INPUT)  * 
*************************  2 
ENTRY 

!  NOTE:  SINCE  ONLY  ONE  PROCESSOR  CURRENTLY 


IN  SYSTEM,  LOCK  NOT  NECESSARY 

• 

♦  *  ♦  DEBUG  ♦  ♦  ♦  ! 

0282 

0D4  1 

CP  5>R4,  #OFF 

0284 

0000 

0286 

5E06 

IF  NE 

!  NOT  UNLOCKED  i  THEN 

0288 

0296* 

0  28A 

2100 

LD 

RO,  #U_L  !  UNAUTHORIZED  LOCK  ! 

028C 

0000 

0  28E 

7601 

LDA 

R  1 ,  $ 

0290 

028E' 

0292 

5F00 

CALL 

MONITOR 

0294 

A900 

FI 

I  *  *  END  DEBUG  *  *  ! 

TEST  LOCK: 

!  DO  WHILE  STRUCTURE  LOCKED  ! 

0296 

0D46 

TSET 

2>R4 

0298 

E5FE 

JR  HI, 

TEST  LOCK 

T  *♦  NOTE  SEE  PLZ/ASM  MANUAL 

FOR  RESTRICTIONS  ON 
USE  OF  TSET.  **  1 

029  A 

9E08 

RET 

029C 


END  SPIN  LOCK 
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029C  ITC_GET_SEG_PTR  PROCEDURE 

»  *** ********* ******* ******** ****** 

*  GETS  BASE  ADDRESS  OF  SEGMENT  * 

*  INDICATED.  * 

********************************* 

*  REGISTER  USE:  * 

*  RO :  SEG  BASE  ADDRESS  (RET)  * 

*  R1 : SEG  NR  (INPUT)  * 

*  R2 : RUNNING_VP  (LOCAL)  * 

*  R3:DBR_VALUE  (LOCAL)  * 

*  R4  :  VP  T . LOCK  * 

*  R1 3 .-LOGICAL  CPU  #  * 

********************************* i 


ENTRY 

!  SAVE  SEGMENT  #  ! 


029C 

93F1 

PUSH 

SR15,  R 1 

!  MASK 

:  INTERRUPTS  ! 

0  29E 

7C01 

DI 

VI 

!  LOCK 

:  VPT  ! 

0  2A0 

7604 

LDA 

R4, VPT. LOCK 

02A2 

0000* 

02A4 

5F00 

CALL 

SPIN_LOCK  !  R4  : VPT .  LOCK 

02A6 

0282* 

!  GET 

CPU  #  ! 

0  2A8 

5F00 

CALL 

GET_CPU_NO  ! RETURNS : 

02AA 

02C8 ' 

SI:  CPU  # 

R2 :  #  VP'S! 

02AC 

A11D 

LD 

R 1  3  ,  R  1 

!  RESTOEE  SEGMENT  #  ! 

02AE 

97F1 

POP 

HI,  5>R  15 

02B0 

61D2 

LD 

R2, VPT.RUNNING_LIST (R13) 

02B2 

0002* 

02B4 

6123 

LD 

R3  ,  VPT .  VP.  DBR(R2) 

02B6 

0010* 

1  UNLOCK  VPT  ! 

02B8 

4D08 

CLR 

VPT. LOCK 

0  2BA 

0000* 

!  UNMASK  VECTORED  INTERRUPTS  ! 

0  2BC 

7C05 

El 

VI 

02BE 

1900 

MULT 

RR0,#4 

0  2C0 

0004 

02C2 

7130 

LD 

R0,R3  (R1 ) 

02C4 

0100 

02C6 

9E08 

RET 

02C8 

END  ITC 

GET  SEG  PTR 
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02C8  GET_CPU_NO  PROCEDURE 

• *******£***************** 

*  FIND  CURRENT  CPO_NO  * 

*  CALLED  BY  DIST  MMGR  * 

*  AND  MM  * 

************************* 

*  RETURNS  * 

*  R1:  CP U_NO  * 

*  R2:  #  OF  VP'S  * 

********  ***************** • 


ENTRY 


02C8 

02CA 

6101  LD 

OAOC' 

si. 

PRDS. LOG_CPU_ID 

02CC 
0  2CE 
02D0 

6102  LD 

OAOE' 

9E08  RET 

82, 

PHDS. VP_NR 

02D2 

END  GET_CPU 

_N0 

0  2D2 

K_ 

LOCK  PROCEDURE 

!************************* 

*  STUB  FOR  WAIT  LOCK  * 

************************* 

*  R4:-LOCK  (INPUT)  * 

************************* » 

ENTRY 

02D2 

5F00 

CALL  SPIN_LOCK 

02D4 

0282' 

0  2D6 

9E08 

RET 

02D8 

END  K_LOCK 

02D8 

K_ 

UNLOCK  PROCEDURE 

i ************************* 

*  STUB  FOR  WAIT  UNLOCK  * 

************************* 

*  R4 :  -'LOCK  (INPUT)  * 

************************** 

ENTRY 

02D8 

0D48 

CLR  3R4 

0  2  DA 

9E08 

RET 

02DC 

END  K_  UN  LOCK 

END 

I NN  ER_TR  AFFIC_CONTROL 
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Appendix  H 

SEGMENT  MANAGES  LISTINGS 


Z8000ASM  2.02 

LOC  OBJ  CODE  STMT  SOURCE  STATEMENT 
SLISTON  STTY 


SE3  MGR 


MODULE 


CONSTANT 

NULL  SEG  :=  -1 

NULL  ACCESS  :  =  4 

max_seg_no  :=  64 

M AX~NO  KST_ENTRI ES  :=  54 

MAX  SEG  SIZE  :=  128 

KST_SEG_NO  :=  2 

NR_OF_KSEGS  :=  10 

TRUE  :=  1 

FALSE  :=  0 

READ  :=  1 

WRITE  :=  0 

i  ****  SUCCESS  CODES  ****  ! 
SUCCEEDED  “  :=  2 

MENTOR_SEG_NOT_KNOWN  :  =  22 

ACCESS  CLASS_NOT_EQ  :=  33 

N  OT_COMP ATIBLE  :=  24 

SEGMENT  TOO  LARGE  :=  25 

NO_SEG_AVAIL  :=  27 

SEGMENT_NOT_KNOWN  :=  28 

SEGMENT_IN_CORE  :=  29 

KERNEL.SEGMENT  :=  30 

IN V  ALID_SEGMENT_NO  :=  31 

NO  ACCESS  PERMITTED  :=  32 

LSAF_SEG_EXISTS  :=  10 

NO_LEAF  EXISTS  :=  11 

ALIAS_DOES_NOT_EXIST  :=  23 

NO_CHILD  TO_DELETE  :=  20 

3_AST_FULL  :=  12 

L_AST_FULL  :=  13 

PROC_CLASS_NOT_GE_SEG_CLASS  :=  41 
LOC AL_MEMO RY_FULL  7=  16 

GLOBAL  MEMORY_FULL  :=  17 

SEC  STOR  FULL  :=  21 
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MONITOR 


X059A 


TYPE 

H_ARR AY 

KST  REC 


ARRAY  [  3  WORD  ] 


RECORD 


[ MM_HANDLE 
SIZE 

ACCESS_MODE 
IN_CORE 
CLASS 
M_S EG_NO 
ENTRY  NUMBER 

] 


H_ ARRAY 

WORD 

BYTE 

BYTE 

LONG 

SHORT_ INTEGER 
SHORT” INTEGER 


ADDRESS 


WORD 


SEG_ARRAY  ARRAY  [ MAX_SEG_SIZE  BYTE] 


INTERNAL 

SSECTIO N  SM_KST_DCL 

!  NOTE:  THIS  SECTION  IS  AN  "OVERLAY" 

OR  "FRAME"  USED  TO  DEFINE  THE 
FORMAT  OF  THE  KST.  NO  STORAGE 
IS  ASSIGNED  BUT  RATHER  THE  KST  IS 
STORED  IN  A  SEPARATELY  OBTAINED 
AREA  (A  SEGMENT  SET  ASIDE  FOR  IT)  ! 

SABS  0 

0000  KST  ARRAY  MAX_  NO_KST_ENT  HIES  KST.REC 

EXTERNAL 

CL ASS_EQ  PROCEDURE 
CLASS  GE  PROCEDURE 
M M_CREATE_ ENTRY  PROCEDURE 
MmIdELETeIeNTRY  PROCEDURE 
MM_ACTIVATE  PROCEDURE 
M  M_DE ACTI V  ATE  PROCEDURE 
M  M_SW  AP_IN  PROCEDURE 
MM_SWAP_OUT  PROCEDURE 
PROCESS~CLASS  PROCEDURE 
ITC_GET~SEG_PTR  PROCEDURE 
SET  DBR  NUMBER  PROCEDURE 
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SSECTION  SM_PROC 
GLOBAL 

0000  CB  EATE_SEG  PROCEDUBE 

j  * * ** ***** ****** *** ****** * ***** i 

!  CHECKS  VALIDITY  OF  CREATE  ! 

!  REQUEST  AND  ! 

!  CALLS  MM_CREATE  IF  VALID.  ! 

l  ******************************  • 

!  REGISTER  USE:  ! 

!  PARAMETERS  ! 

!  HI:  MENTOR  SEG_NO (INPUT)  ! 

!  R2:  ENT RY_NO (INPUT)  ! 

!  R3:  SIZE  (INPUT)  ! 

!  RR4:  CLASS  (INPUT)  ! 

!  RO:  SUCCESS_CODE  (RETURNED)  ! 

!  LOCAL  USE  ~  ! 

!  R9 :  KST  REC  INDEX  I 

•  R6,R7  VARIOUS  USES  ! 

!  R13:  -.KST  ! 

i ****** ****************** ****** i 


ENTRY 


0000 

0B03 

CP  R3 

, #MAX_SEG_SIZE 

0002 

0080 

0004 

5E02 

IF  GT 

THEN 

0006 

0010' 

0008 

2100 

LD 

RO , #SEGMENT_TOO_L ARGE 

000A 

0019 

OOOC 

5E08 

ELSE 

000E 

0CA2' 

0010 

030F 

SUB 

R15,*10  1STACK  AREA  FOR 

INPUT  REGS! 

0012 

000  A 

0014 

1CF9 

LDM 

dR15,R 1,#5 

0016 

0104 

0018 

2101 

LD 

R1, #KST_SEG_NO 

001  A 

0002 

001C 

5F00 

CALL 

ITC_GET_SEG_PTR  !R1:  KST_SEG_NO! 

001E 

0000* 

!  RET:  RO:  -«KST  ! 

0020 

A10D 

LD 

R  13 , RO  ! KST  BASE  ADDRESS 

(IE  -.KST)  ! 

0022 

1CF  1 

LDM 

R1,o)R15,#5  !  RESTORE  NEEDED  REGS! 

0024 

0104 

0026 

A119 

LD 

R9,R1  .'COPY  OF  MENTOB_SEG_NO  ! 

0028 

0309 

SUB 

R9, #NR_OF_KSEGS  !CONVERT 

MENTOR_SEG_NO 

002  A 

000  A 

KST  REC  INDEX! 

0  02C 

1908 

MULT 

RR8 , tSIZEOF  KST_REC 

iOFFSET  TO  KST  REC! 
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002E 

0010 

0  0  30 

8  19D 

ADD  R13,R9  1  ADD  OFFSET  TO  KST 

BASE  ADDRESS! 

0032 

2106 

LD  R6 

, #NULL_SEG 

0034 

FFFF 

0036 

4ADE 

CPB  RL6,KST.M  SEG  NO(R13) 

0038 

000  E 

003A 

5E0E 

IF  EQ 

THEN  ! MENTOR  SEG  NOT  KNOWN! 

003C 

0046' 

003E 

2100 

LD 

RO, #MENTOR_SEG_NOT_KNOWN 

0040 

0016 

0042 

5E08 

ELSE 

0044 

009E' 

0046 

93FD 

POSH 

a)R  1 5  ,  R1  3 

0048 

5F00 

CALL 

P ROC ESS_C LASS  ! RR2: PROC_CLASS! 

004A 

0000* 

004C 

97FD 

POP 

R  1 3,  a)Rl  5 

004E 

54D4 

LDL 

RR4, KST. CLASS  (R13) 

0050 

000  A 

0052 

93FD 

PUSH 

a)R  15 ,  R1  3 

0054 

5F00 

CALL 

CLAS S_EQ  ! R£2 :  PROC_CLASS! 

0056 

0000* 

! RR4:  MENTOR  SEG  CLASS! 

! B1 :  (RET) CONDITION  CODE! 

0058 

97FD 

POP 

R  1 3,  alR  1  5 

005A 

A116 

LD 

R6,R  1 

005C 

1CF  1 

LD  M 

R1,3R15,#5  IRESTORE  INPUT  REGS 

0  05E 

0104 

0060 

0B06 

CP 

R6, #FALSE 

0062 

0000 

0064 

5S0E 

IF  EQ 

|  THEN 

0066 

0070' 

0068 

2100 

LD 

RO , *ACCESS_CLASS_NOT_EQ 

006  A 

0021 

006C 

5E08 

ELSE 

006E 

00  9  E* 

0070 

93FD 

POSH 

5)R15,R13  !  SAVE  -.KST! 

0072 

9442 

LDL 

RR2,RR4  ! CLASS ! 

0074 

54D4 

LDL 

RR4, KST. CLASS  (R13) 

0076 

000  A 

0078 

5F00 

CALI 

,  CLASS_GE  !RR2:  CLASS! 

007A 

0000* 

!RR4: MENTOR  CLASS! 

! RET: HI :COND_CODE! 

007C 

97FD 

POP 

R1  3,o)R  1  5  IRESTORE  PTR! 

007E 

0B0  1 

CP 

R 1  , #F ALSE 

0080 

0000 

0082 

1CF  1 

LD  M 

R1 ,  a)R  1 5 ,  #  5 

0084 

0104 

0086 

5E0E 

IF 

EQ  THEN 

0088 

0092* 

0  08A 

2100 

LD 

i  RO, #N0T_C0MPATI3LE 
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0 08C  0018 
008E  5E08 
0090  009E' 
0092  76D 1 
0094  0000 
0096  5F00 
0098  0000* 


009A  5P00 
009C  0428' 


0 09E  010F 
00 AO  000 A 

00A2  9E08 
00A4 


ELSE 

LDA  R1,KST.  MM_HANDLE  (R  1  3) 

CALL  MM_CREATE_ENTBY 

! R1 : PTR  TO  MH_HANDLE! 
!R2:ENTRY_N0!~ 

!  R3  :SIZE!  ~ 

!  RR4 : CLASS ! 

!R0: (RETURNED) SOCCESS_CODE! 
CALL  CONFINEMENT_CHECK 

!  (RO  :SUCCESS_CODE)  ! 

FI 

FI 

FI 

ADD  R 15  ,  #  1 0 


FI 

RET 

END  CREATE  SEG 
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00A4 

DELETE_ 

SEG  PROCEDURE 

t 

****************** ***********t 

I 

CHECKS 

VALIDITY  OF  DELETE  1 

f 

REQUEST  AND  « 

f 

CALLS 

MM  DELETE  IF  VALID.  ! 

« 

***************************** » 

1 

f 

REGISTER  USE:  i 

PARAMETERS  ! 

1 

1 

• 

j 

R 1:  MENTOR_SEG_NO (INPUT)  ! 

R2:  ENTRY_NO  (INPUT)  ! 

RO:  SUCCESS  CODE  (RET)  ! 

» 

LOCAL 

USE  ! 

i 

R6: VARIOUS  LOCAL  USES  ! 

i 

********************** *******1 

ENTRY 

00A4 

93F  1 

PUSH 

3R15,R1  1SAVE  NEEDED  REGS! 

00A6 

93F2 

PUSH 

5IR  15r  R2 

00A8 

2101 

LD 

R1 , #KST_SEG_NO 

OOAA 

0002 

0  0  AC 

5F00 

CALL 

ITC_GET_SEG_PTR  ! Rl: KST_SSG_NO 

00  AE 

0000* 

OOBO 

A10D 

LD 

R13,R0  i-'KST! 

00B2 

97F2 

POP 

R2 , 3R  15  'RESTORE  INPUT  REGS' 

00B4 

97  F 1 

POP 

Rl ,3R  15 

00B6 

0301 

SUB 

R  1  ,  #N  R  OF  KSEGS  'CONVERT 

M  ENTOR_SEG_NO  TO 

00B8 

OOOA 

KST  REC  INDEX! 

OOBA 

1900 

MULT 

RR  0  ,  #SI2  EOF  KST_REC  .'OFFSET 

TO  DESIRED  REC! 

OOBC 

0010 

OOBE 

81  ID 

ADD 

R13,R1  !  ADD  OFFSET  TO  KST  BASE 

ADDRESS! 

OOCO 

2106 

LD 

R6  ,  #NULL_SEG 

00C2 

FFFF 

0  0C4 

4ADE 

CPB 

RL6,KST. M_SEG_NO (R13) 

00C6 

OOOE 

00C8 

5E0E 

IF 

EQ  THEN  ! MENTOR  SEGMENT 

NOT  KNOWN! 

OOCA 

00D4  * 

OOCC 

2100 

LD 

RO, #ME  NTOR_SEG_NOT_KNOWN 

OOCE 

0016 

OODO 

5E08 

ELSE 

00D2 

010E' 

00D4 

93F1 

PUSH 

3R1 5 , R 1  1SAVE  NEEDED  REGS! 

00D6 

93F2 

PUSH 

3R 1 5 , R  2 

00D8 

93FD 

PUSH 

3R  1  5 , R  1 3 

OODA 

5F00 

CALL 

PROCES  S_CLASS 

0  ODC 

0000* 

!  (RETURNS  RR2 :PROC_CLASS)  ! 

OODE 

97FD 

POP 

R13 , 3R  15 

OOEO 

54D4 

LDL 

RR4, KST. CLASS  (R13)  IMENTOR 
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SEG  CLASS! 


0  0E2 

OOOA 

00E4 

93FD 

PUSH 

SR15, R13 

00E6 

5F00 

CALL 

CLASS_EQ  ! RR2 : PROCESS  CLASS! 

00E8 

0000* 

! RR4 : MENTOR  SEG  CLASS! 

! R 1 ;  (RET)  CONDIIION_CODE 

00EA 

A116 

LD 

R6 ,  R  1 

0  OEC 

97FD 

POP 

R 13 , SR  15 

OOEE 

97F2 

POP 

R2, SR  1  5  IRESTORE  NEEDED  REGS 

OOFO 

97F1 

POP 

R 1 r  SR  1 5 

00F2 

0B06 

CP 

R6 , #FALSE 

00F4 

0000 

00F6 

5E0E 

IF 

EQ  THEN 

00F8 

0102’ 

OOFA 

2100 

LD 

RO , # ACCESS_CLASS_NOT_EQ 

OOFC 

00  21 

OOFE 

5B08 

ELSE 

0100 

010E» 

0102 

76D 1 

LD  A  R  1 ,  KST.  MM  HAN  OLE  (R  1  3) 

0104 

0000 

0106 

5F00 

CALL  MM  DELETE  ENTRY 

0108 

0000* 

!  HI: 

-«M  M_H  ANDLE ! 

!  R2 : 

ENTRY  NO! 

!  RO: 

(RET)  SUCCESS_CODE  i 

0  10A 

5F00 

CALL  CONFINEMENT_CHECK 

0  IOC 

0428* 

!  (RO 
FI 

:SOCCESS_CODE) ! 

FI 

0  10E 

9E08 

RET 

0110 

END  DELETE_SEG 
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0110  MAKE_KNOWN  PROCEDURE 

!  CHECKS  VALIDITY  OP  HAKE  KNOWN 
!  REQUEST  AND  CALLS  MM_ ACTIVATE 
!  IF  VALID.  ASSIGNS  SEG 
!  NUMBER  AND  UPDATES  KST. 

; ******************************* 

!  REGISTER  USE: 

!  PARAMETERS: 

!  R1  :MENTOR_SEG_NO  (INPUT) 

!  R2 :SNTRY_NO (INPUT) 

!  R3  :  ACCESS_DESIRED  (INPUT) 

!  RO  :SUCCESS_CODE  (RET) 

!  R1  :SEGMENT_NO  (RET) 

!  R2  :  ACCESS_ALLOWED  (RET) 

!  LOCAL  USE 

!  IDENTIFIED  AT  POINT  OF  USAGE 

i ******************************* 

ENTRY 


0110 

93F1 

PUSH 

a)R  15,  R  1  !SAVE  INPUT  REGS! 

0112 

91F2 

PUS  HL 

2>R  1  5  ,  RR2 

0  1  14 

2101 

LD 

R 1 ,  #KST_SEG_NO 

0116 

0002 

0118 

5F00 

CALL 

ITC_GET_SEG_PTE  i  (R 1 : KST_SEG_NO , 

RET:R07-.KST)  ! 

0  1 1 A 

0000* 

01  1C 

A10D 

LD 

R1 3 ,  RO  !-KST! 

01  IE 

95F2 

POP  L 

RR2,dR15 

0120 

97F 1 

POP 

R1,2R15 

0122 

A1  15 

LD 

R5,R1  ! COPY  OF  MENTDR_SEG_NO! 

0124 

0305 

SUB 

R5,#NR  OF_KSEGS  ICONVERT  TO 

INDEX  ! 

0126 

000A 

0128 

1904 

MULT 

RR  4  , #SIZ EOF  KST  REC  ! KST  OFFSET 

TO  SEG  REC! 

012A 

0010 

0  12C 

8 15D 

ADD 

R1 3 ,R5  !  ADD  OFFSET  TO  -*KST  ! 

012E 

2104 

LD 

R4 , #NULL_SEG 

0130 

FFFF 

0132 

4ADC 

CPB 

RL4  rKST. M_SEG_NO (R 13) 

0  134 

000E 

0136 

5E0E 

IF  EQ 

THEN 

0138 

0 14A ' 

013A 

2100 

LD 

RO, #MENTOR_SEG_NOT_KNOWN 

013C 

0016 

0  13E 

2101 

LD 

R 1 , #NULL_SEG 

0140 

FFFF 

0142 

2102 

LD 

R2, #NULL_ACCSSS 

0144 

0004 

0146 

5E08 

ELSE 

0148 

02C8 ' 

0  14A 

2107 

LD 

R7,V0  ! KST  INDEX! 

014C 

0000 
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0  14E 

2108 

LD  R8,#NULL_SEG  'AVAIL  SEG  INDEX! 

0  150 

FFFF 

0152 

A 109 

LD  R9,R0  I-.KST! 

0  154 

2  10  A 

LD  RIO, #NULL_SEG  !SEG  KNOWN  INDICATOR 

0156 

FFFF 

SEE_IF_KNOWN: 

DO 

0  158 

4A99 

CPB  RL1,KST.M_SEG_N0(R9) 

0  1 5  A 

000E 

0  15C 

5E0E 

IF  EQ  THEN 

015E 

017C' 

0  160 

4A9  A 

CPB  RL2, KST. E NT RY_N UMBER (R9) 

0162 

OOOF 

0164 

5E0E 

IF  EQ  THEN  ICASE:  SEG  KNOWN! 

0166 

017C» 

0168 

2100 

LD  RO , #S  QCCEED  ED 

0  16  A 

0002 

016C 

0107 

ADD  R7, #NR_OF_KSEGS 

0  16E 

000  A 

0170 

A17  1 

LD  R 1  ,  R7  !  S  EG  #  ! 

0172 

609A 

LDB  RL2, KST . ACCESS_MODE (R9) 

0174 

0008 

0176 

A 1  1 A 

LD  RIO, HI  ! SET  SEG  KNOWN 

INDICATOR! 

0178 

5208 

EXIT  FROH  SEE_IF_KNOWN 

017A 

01 A6 ' 

PI 

FI 

017C 

4  A9C 

CPB  RL4,KST.M_SEG_N0(R9) 

! SEE  IF  SEG  *  AVAIL! 

017E 

OOOE 

0180 

5E0E 

IF  EQ  THEN 

0182 

0192* 

0184 

OB08 

CP  R8, f NULL_SEG 

0186 

FFFF 

0188 

5E0E 

IF  EQ  THEN 

018A 

0192* 

0  18C 

A178 

LD  R8,R7  .‘SAVE  FIRST 

AVAIL  SEG  INDEX! 

018E 

0108 

ADD  R8,#NR  OF  KSEGS 

ICONVERT  TO  SEG  #! 

0  190 

000  A 

FI 

FI 

0192 

A970 

INC  R7 

0194 

0109 

ADD  R9, #SIZE0F  KST_REC 

! INCREMENT  ONE  REC! 

0196 

0010 

0198 

0B07 

CP  R7, #MAX_NO_KST_ENTRIES 

0  19A 

0036 

019C 

5E02 

IF  GT  THEN 

019E 

0 1 A4 ' 
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01  AO 

5E08 

EXIT  FROM  SEE  IF  KNOWN 

01  A2 

0 1 A6  1 

FI 

01  A4 

E8D9 

OD 

! SEE_IF_KNOWN! 

0  1  A6 

OBOA 

CP  ~  R?0,#NULL  seg 

0  1  A8 

FFFF 

01  AA 

5E0E 

IF  EQ  THEN  ISEG  KNOWN 

INDICATOR  NOT  SET! 

0  1  AC 

02C8 ' 

0  IAS 

0B08 

CP  R3 , # NULL  SEG 

0  1B0 

FFFF 

01B2 

5E06 

IF  NE  THEN  !CASE:SEG  UNKNOWN 

AND  SEG#  AVAIL! 

01B4 

02BC’ 

0  1B6 

91F0 

PUSHL 

SR15,RR0  !  -'KST  AND 

MENTOR_SEG  NO! 

01B8 

91F2 

PUS  HL 

SR15,RR2  ! ENTRY_NQ~ 

& ACCESS  DESIRED! 

0  1  BA 

93F8 

PUSH 

SR  1  5, R8  ! AV AIL  SEG 

INDEX  IN  KST! 

01  BC 

93FD 

PUSH 

SR  1 5, R 1 3  1MENTOR  SEG  REC  PTR 

0  1  BE 

5F00 

CALL 

GET  DBR  NUMBER 

!  (RET 

:rli7dbr”no)  ! 

0  ICO 

0000* 

01C2 

A1  1  A 

LD 

RIO, HI  ! DBR  NO! 

01C4 

97  FD 

POP 

R 1 3  ,SR  1  5 

0  1C6 

97F8 

POP 

R8 , SR  1 5 

01C8 

95F2 

PO  PL 

RR2,SR1 5 

0  1 CA 

95F0 

PO  PL 

RRO, SRI  5 

! MUST  REARRANGE  REGS  FOR  PASSING  AND 

RETURN  CONSISTENCY  OF  LOCATION! 

0  ICC 

A135 

0  OOD 

047C 

5E0E 

LD 

R5,R3  JACCESS  DESIRED! 

0  ICE 

A 1 23 

LD 

R3,R2  ! ENTRY  NO! 

01  DO 

76D2 

LD  A 

R2 , KS T.  MM_H ANDLE  (R  1 3)  !  HPTR! 

01D2 

0000 

01D4 

A1 16 

LD 

R6,R1  !MENTOR_SEG_NO ! 

01D6 

A 1  8 1 

LD 

R1,R8  !SEGMENT_NO~  (S  AVE)  ! 

0  1D8 

A 1  84 

LD 

R4,R8  !SEGMENT_NO 

(PASSING  ARG)  ! 

01  DA 

A109 

LD 

R9,R0  !  -»KST ! 

0  1  DC 

030F 

SUB 

R  15,#20 

01  DE 

0014 

0  1E0 

1CF9 

LDM 

SR15,R1,#10  !SAYE  REGS  1-10! 

0  1E2 

0109 

0  1E4 

A  1 A  1 

LD 

R 1 ,  R1  0  !DBR_N0  PASSED 

IN  R  1 ! 

0  1E6 

A 1 8B 

LD 

811,  R8 

01E8 

030B 

SUB 

R11,  #NR_OF_KSEGS 

0  1  EA 

000  A 

0 1  EC 

190A 

MULT 

RR  1 0,  #SIZEOF  KST_REC 

0  1  EE 

0010 
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0  1  FO 

A1BC 

LD 

R 1 2 ,  R11 

0  1F2 

819C 

ADD 

R 1  2 ,  R9 

0  1F4 

5F00 

CALL 

MM  ACTIVATE 

0  1F6 

0000* 

!(R1:DBB  NO,R2:HPTR,R3;ENTRY_NQ, 

R4  :  SEGUE  NT 

NO  , R1 2 : RET_HPTR)  ! 

!  (RET: RO : SUCCESS_CQDE# RR2:CLASS, 

R4:SIZE)  ! 

01F8 

5F00 

CALL  CONFINEMENT  CHECK 

1 

(RO:SUCCESS_CODE)  ! 

0  1  FA 

0428' 

0  1 FC 

942A 

LDL 

RR 1 0, RR2  ! CLASS ! 

0  1 FE 

A14C 

LD 

R1 2 ,R4  ! SIZE! 

0200 

1CF 1 

LDM 

R1,a>R15,#9  !  RESTORE 

REGS  1 

0202 

0108 

0204 

A187 

LD 

R7,R8  ! S EG  #! 

0206 

0307 

SUB 

R7  ,  #NR_OF_KSEGS 

0208 

000  A 

0  20  A 

1906 

MULT 

RR6 , #SIZEOF  KSI_REC 

•OFFSET  TO  RECI 

020C 

0010 

020E 

A17D 

LD 

R13,R7 

0210 

819D 

ADD 

R 1 3 ,R9  ‘ADD  -KSI  TO 

OFFSET 

0212 

5DDA 

LDL 

KST. CLASS  (R  13)  ,RR10 

! CLASS 

0214 

000  A 

0216 

6FDC 

LD 

KST. SIZE (R1 3) ,R12  1SIZE! 

0218 

0006 

02  1 A 

0A08 

CPB 

RLO , #SUCC EEDED 

0  21C 

0202 

0  2 1 E 

5E0E 

IF  EQ 

THEN 

0220 

02  AC ' 

0222 

93FD 

PUSH 

a)R15#  R1  3 

0  224 

5F00 

CALL 

PROCESS_CLASS 

0226 

0000* 

!  (RET : RR2 : PROC_CLASS)  ! 

0228 

97FD 

POP 

R 13  ,  a)R1  5 

022A 

54D4 

LDL 

RR4, KST. CLASS  (R13) 

0  22C 

000  A 

022E 

93FD 

PUSH 

a)R15, R1 3 

0230 

91F2 

PUSHL  SR15,RR2 

0232 

91F4 

PUSHL  dR15,RR4 

0234 

5F00 

CALL 

CLASS_G  E 

0236 

0000* 

!  (RR2 :  PROC 

_CLASS, RR4; SEG  CLASS 

,  RET: 

HI: 

CONDITION  CODE)  ! 

0238 

95F4 

POPL 

RR4, 3R1  5 

0  23A 

95F2 

POPL 

RR2  ,  a)R1  5 

023C 

97FD 

POP 

R13,5)R1  5 

0  23E 

0B01 

CP 

HI, #F ALSE 

0240 

0000 

0  242 

5E0E 

IF  EQ  THEN  !NO  ACCESS 

POSSIBLE — DEACT. ! 

0244 

0266' 
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R1,SE15,#10 


0  246 

1CF1 

0248 

0109 

0  24  A 

A1A1 

024C 

76D2 

024E 

0000 

0250 

5F00 

0252 

0000* 

0254 

5F00 

0256 

0428' 

0258 

21F1 

0  25  A 

2102 

025C 

0004 

0  25E 

2100 

0260 

0029 

0262 

5E08 

0264 

02A8 ' 

0266 

93FD 

0268 

5F00 

026  A 

0000* 

0  26C 

97FD 

026E 

A110 

0270 

1CF 1 

0272 

0108 

0274 

0B00 

0276 

0001 

0278 

5E0E 

027A 

0290* 

027C 

0B05 

0  27E 

0000 

0280 

5E0E 

0282 

028A' 

0284 

CAOO 

0286 

5E08 

0288 

028C* 

0  28A 

CA01 

028C 

5E08 

028E 

0292' 

0290 

CAO  1 

0292 

4CD5 

0294 

0009 

0296 

0000 

0298 

6EDE 

029A 

000E 

029C 

6EDB 

029E 

000F 

LDM 

LD  R1,R10  ! DBB  NOi 

LDA  B2,  KST.  MM_HANDLE  (HI 3) 

i HPTEi 

CALL  MM_DE ACTIVATE 

!het7eo:s_codei 

CALL  CONFI NEMENT_CHECK 

l RO: S_CODEl 

LD  R1,SB15  !SEG  #! 

LD  R2, #NULL_ACCESS 

LD  HO, 

# P HOC _CLASS_NOT_GE_SEG_C LASS 

ELSE 

PUSH  a)R1  5,  HI  3 

CALL  CLASS_EQ  ! (EH2 : PBOC_CLASS , 

RH4 : S EG  CLASS, 
RET:  HI  :CONDITION_CODE)  ! 
POP  R  13 , SRI  5 

LD  R0,R1  !CONDITION_CODEJ 
LDM  R1,SR15,#9 

CP  R0,#TRUE 

IF  EQ  THEN 

CP  R5, iWRITE 

IF  EQ  THEN 

LDB  HL2,#HRIIE 
ELSE 

LDB  HL2,#READ 
FI 
ELSE 

LDB  RL2 , #  READ 
FI 

LDB  KST.IN  CORE (R13) , tFALSE 


LDB  KST . M_SEG_NO  (R 1 3)  ,HL6 
LDB  KST. ENTRY_NUMBER ( R 1 3 ) ,RL3 
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0  2  AO 

6EDA 

LDB 

KST.ACCESS_MODE (R13>  , RL2 

02A2 

0008 

02A4 

2100 

LD 

RO,  ^SUCCEEDED 

! SUCCESS _ CODE ! 

02A6 

0002 

FI 

02A8 

5E08 

ELSE 

02AA 

02B4  • 

0  2  AC 

2101 

LD 

HI, #NULL_SEG 

02AE 

FFFF 

02B0 

2102 

LD 

R2, #NULL_ACCESS 

02B2 

0004 

FI 

02B4 

01  OF 

ADD 

R 1 

5,  #20 

02B6 

0014 

02B8 

5E08 

ELSE 

02BA 

02C8' 

023C 

2100 

LD 

RO 

, #NO_SEG_ AV  AIL 

02BE 

00  IB 

0  2C0 

2101 

LD 

R  1 

,#NULL_SEG 

02C2 

FFFF 

02C4 

2102 

LD 

R2 

,#NULL_ACCESS 

0  2C6 

0004 

FI 

FI 

FI 

02C8  9E08  RET 
0  2CA  END  MAKE  KNOWN 
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02CA  TERMINATE  PROCEDURE 

j  ****************************** 

!  CHECKS  VALIDITY  OF  TERMINATE 
!  REQUEST  AND  CALLS 
!  MM_ DEACTIVATE  IF  VALID 
»  ****************************** 
!  REGISTER  USE 
!  PARAMETERS 
I  R1  :SEGMENT_NO  (INPUT) 

!  RO :SUCCESS_CODE (BET) 

!  LOCAL  USE 
!  R3 : KST  REC  INDEX 
!  R6:CONSTANT  STORAGE 
!  R1  3:  -»KST 

i ****************************** 


ENTRY 

02CA 

A1 13 

LD 

R3,R1  ! COPY  OF  SEG  #! 

02CC 

0303 

SUB 

R3 , #NR  OF  KSEGS 

'.CONVERT  SEG#  TO  KST  INDEX! 

02CE 

000  A 

02D0 

1902 

MULT 

RR 2 / #SIZ EOF  KST_REC 

02D2 

0010 

02D4 

93F 1 

POSH 

a)R  1  5  ,  R 1 

02D6 

93F3 

POSH 

a>R  1  5,  R3 

02D8 

2101 

LD 

R1 , #KST_SEG_NO 

02DA 

0002 

02DC 

5F00 

CALL 

ITC  GET  SEG  PTR 

!  ( R  1 : KST_SEG_NO)  ! 

02DE 

0000* 

!  (RETURNS: RO ; KST_SEG_PTR)  ! 

02E0 

A10D. 

LD 

R1  3  #  RO 

02E2 

97F3 

POP 

R3  ,  a)R  1  5 

0  2E4 

97F 1 

POP 

R 1 r  SR  15 

02E6 

81 3D 

ADD 

R13,R3  !ADD  OFFSET  TO  -«KST 

0  2E8 

2106 

LD 

R6  f #N  ULL_SEG 

02EA 

FFFF 

0  2EC 

4ADE 

CPB 

RL6,KST.  M_SEG_NO  (R 1 3) 

0  2EE 

000E 

02F0 

5E0E 

IF 

EQ  THEN 

02F2 

02FC* 

0  2F4 

2100 

LD  RO , #SEGMENT_NOI_KNOWN 

02F6 

001C 

02F8 

5E08 

ELSE 

02FA 

0346' 

0  2FC 

2106 

LD  R6  , #TRUE 

02FE 

0001 

CPB  RL6,KST.IN_CORE (R13) 

0300 

4  ADE 

0302 

0009 

0304 

5E0E 

IF 

EQ  THEN 

0306 

0310' 

0308 

2100 

LD  RO, #SEGMENT_IN_CORE 
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0  3  0A 

00  ID 

0  30C 

5E08 

ELSE 

030E 

0346* 

0310 

0B01 

CP 

R1, #NR_OF_KSEGS 

0312 

000  A 

0314 

5E09 

IF  LT  THEN 

0316 

0320* 

0318 

2100 

LD 

RO , tKERNEL^SEGMENT 

03  1A 

00  IE 

03  1C 

5E08 

ELSE 

0  3 1 E 

0346* 

0320 

93FD 

PUSH 

SR 15r  R13 

0322 

5F00 

CALL 

GET_DBR_N UMBER 

0324 

0000* 

!  (RETURNS.-RL1  :DBR  NO)  I 

0326 

97PD 

POP 

R13,SR15 

0328 

76D2 

LD  A 

R2,KST.MM_HANDLE (R13) 

032A 

0000 

0  32C 

93FD 

PUSH 

SR  1 5, S 1 3 

032E 

5F00 

CALL 

MM_ DEACTIVATE  i(R1:DBR 

0330 

0000* 

!  (R2:-»MM_HANDLE)  i 

i 

(RET:  RO  :  SUCcIsS^CODE)  ! 

0332 

5F00 

CALL 

CONFINEMENT.CHECK 

0334 

0428' 

l  (R  0 :  SUCCESS_CODE)  ! 

0336 

97FD 

POP 

R13,SR15 

0338 

OA08 

CP  B 

RLO,#SUCCEEDED 

033A 

0202 

033C 

5E0E 

IF 

EQ  THEN  {UPDATE  KST 

033E 

0346' 

0340 

4CD5 

LDB 

KST .  M_S EG_NO(R13)  , 

0342 

OOOE 

0344 

FFFF 

FI 

#NULL_SEG 

FI 

FI 

FI 

0346 

9E08 

RET 

0348  END  TERMINATE 
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0348 


SM  SWAP  IN 


PROCEDURE 


**************************** 

CHECKS  VALIDITY  OF  SWAP  IN 
REQUEST  AND  CALLS 
MM_SWAP_IN  IF  VALID 
**************************** 
RESISTER  USE 
PARAMETERS 
R1  : S EGM ENT_NO  (INPUT) 

RO  :SUCCESS_CODE  (RET) 

LOCAL  USE 
R7 : KST  REC  INDEX 
R3  :  ACCESS_MODE 
R6 : CONSTANT  STORAGE 
HI  3:-»KST 

********* ******************* 


ENTRY 

0348 

A 1 17 

LD 

R7,R1  SCOPY  OF  SEG  #! 

034  A 

0307 

SUB 

R7,#NR  OF  KSEGS 

'.CONVERT  SEG#  TO  KST  INDEX! 

034C 

000A 

0  34E 

1906 

MULT 

RR6 , tSIZEOF  KST_REC 

! OFFSET  TO  KST_REC! 

0350 

0010 

0352 

93F1 

PUSH 

a)R  15,R1  ! S A V E  SEGMENT*! 

0354 

93F7 

PUSH 

3R15,R7 

0356 

2101 

LD 

HI ,#KST_SEG_NO 

0358 

0002 

0  35  A 

5F00 

CALL 

ITC_GET_SEG_PTR  !R1:KST_S 

0  35C 

0000* 

035E 

A10D 

LD 

R1  3  ,  RO  !  -«KST  ! 

0360 

97F7 

POP 

R7  ,  a)R  15 

0362 

97  F 1 

POP 

R1  ,  a)R  1 5  !  RETRIEVE  SEGMENT# 

0364 

817D 

ADD 

R 1 3 , R7  ! ADD  OFFSET  TO  KST 

0366 

2106 

LD 

R6 , #NULL_SEG 

0368 

FFFF 

0  36  A 

4ADE 

CPB 

RL6  ,  KST.  M_SEG_NO  (R 1  3) 

0  36C 

000E 

0  36E 

5E0E 

IF 

EQ  THEN 

0370 

037A* 

0372 

2100 

LD 

RO,  #SEGMENT_NOT_KNOWN 

0374 

001C 

0376 

5E08 

ELSE 

0378 

03B8* 

037A 

2106 

LD 

R6 , #TR  UE 

0  3  7C 

0001 

0  37E 

4ADE 

CPB 

RL6 ,KST.IN_CORE  (R13) 

0380 

0009 

0382 

5S0E 

IF 

EQ  THEN 

0384 

038E ' 

0386 

2100 

LD  RO, #SUCCEEDED 
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0388 

0002 

038  A 

5E08 

ELSE 

038C 

03B8 ' 

038E 

93FD 

POSH 

3R15,R13  ! S AVE  KST  REC  ADDS 

0390 

5F00 

CALL 

GET_DBR_NOMBER  !R  1 ;  (RET )  DBR 

0392 

0000* 

0394 

97FD 

POP 

R13, 3R15 

0396 

76  D2 

LDA 

R2,KST. MH_H ANDLE (R 13) 

0398 

0000 

039A 

60DB 

LDB 

RL3, KST. ACCESS_MODE  (R13) 

039C 

0008 

039E 

93FD 

POSH 

3R 15 ,R1 3  ISAVE  SEG  KST  REC 

0  3  AO 

5F00 

CALL 

MM_SWAP_IN  !R1:DBR_NO  l 

03A2 

0000* 

s  a  2: 

-'tlH  HANDLE! 

!R3: 

ACCESS_MODE! 

!  RO: 

(RET)  S OCC ESS _ CODE ! 

03A4 

5F00 

CALL 

CONFINEMENT.CHECK 

!  (RO  ;  SUCCESS_CODE)  ! 

03A6 

0428* 

03A8 

97FD 

POP 

R 1 3#  3R1 5 

0  3  AA 

0A08 

CPB 

RLO, #SUCCEEDED 

0  3  AC 

0202 

03AE 

5E0E 

IF 

EQ  THEN 

03B0 

03B8 ' 

0  3B2 

4CD5 

LDB  KST.IN  CORE  (R13)  ,#TROE 

03B4 

0009 

03B6 

0101 

FI 

FI 

FI 

03  B8 

9E08 

RET 

03BA 


END  SM  SWAP  IN 
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03BA 


PEOCEDUBE 


SM_SWAP_OUT 

***************************** 

CHECKS  VALIDITY  OF  SWAP  OUT 
REQUEST  AND  CALLS 
MM_SWAP_OUT  IF  VALID 
***************************** 
RESISTER  USE 
PARAMETERS 
R1 :SEGMENT_NO 
RO  :SUCCESS~CODE  (RET) 

LOCAL  USE 
R7  :  KST  REC  INDEX 
R6:CONSTANT  STORAGE 
R13:-KST 

***************************** 


ENTRY 

03  BA 

A1  17 

LD 

R7, R1  ! COPY  OF  SEG  #! 

0  3BC 

0307 

SUB 

R7,#NR  OF  KSEGS 

1CONVERT  SEG#  TO  KST  INDEX! 

03BE 

000  A 

03C0 

1906 

MULT 

RR6 , #SIZ EOF  KST  REC 

•OFFSET  TO  KST  REC! 

03C2 

0010 

03C4 

93F1 

PUSH 

dR15,R1  ISAVE  SEGMENT#! 

03C6 

93F7 

PUSH 

a)R  1  5  ,  R7 

03C8 

2101 

LD 

R1 , #KST_SEG_NO 

03CA 

0002 

0  3CC 

5F00 

CALL 

ITC_GET_SEG_PTR  !R1:KST_SEG_ 

0  3CE 

0000* 

03D0 

A10D 

LD 

R 1 3  , RO  !  -«KST ! 

03D2 

97F7 

POP 

R7  ,  a)R  15 

03D4 

97F1 

POP 

R 1  ,  a)R  1  5  IRETRIEVE  SEGMENT#! 

0  3D6 

817D 

ADD 

R 1 3 ,R7  ! ADD  OFFSET  TO  KST 

BASE  ADDR! 

0  3D8 

2106 

LD 

R6 , #NULL_SEG 

03  DA 

FFFF 

0  3DC 

4ADE 

CPB 

RL6 ,KST. M_SEG_NO(R13) 

0  3  DE 

000E 

0  3E0 

5E0E 

IF 

EQ  THEN 

03E2 

03EC' 

0  3E4 

2100 

LD 

RO , # SE G ME NT_NOT_ KNOWN 

03E6 

00  1C 

03E8 

5E08 

ELSE 

0  3EA 

0426' 

03EC 

2106 

LD 

R6 , #F  ALSE 

03EE 

0000 

03F0 

4ADE 

CPB 

RL6,KST.IN_CORE(R13) 

03F2 

0009 

03F4 

5E0E 

IF 

EQ  THEN 

0  3F6 

0400' 

03F8 

2100 

LD  RO , tSUCCEEDED 
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0  3  FA 

000  2 

03  FC 

5E08 

ELSE 

0  3FE 

0426' 

0400 

93FD 

PUSH 

a)R15  ,R1  3  ISAVE  KSX  EEC  ADDR ! 

0402 

5F00 

CALL 

GET_DBR_N UMBER  I R 1 ; (RET) DBR_NO! 

0404 

0000* 

0406 

97  FD 

POP 

R  1 3,  a)Rl  5 

0408 

76D2 

LDA 

R2  ,  KST.  MM_HAN  DLE  (R  1  3) 

040A 

0000 

040C 

93FD 

PUSH 

a>R  15,R1 3  ISAVE  SEG  KST  REC  ADDR! 

040E 

5F00 

CALL 

MM_SWAP_OUT  !R1:DBR_NO! 

04  10 

0000* 

!  R  2 : 

-•MM  HANDLE! 

!  RO: 

(RET) SUCCESS_CODE! 

0412 

5F00 

CALL 

confinementIcheck 

!  (RO 

:SUCCESS_CODi) ! 

04  14 

0428' 

0416 

97FD 

POP 

R  1 3  ,  a)R1  5 

0418 

0A08 

CPB 

RLO,  tSUCCEEDED 

04  1A 

0202 

04  1C 

5E0E 

IF 

EQ  THEN 

04  IE 

0426' 

0420 

4CD5 

LDB  KST.IN  CORE  (R13)  ,  #FALSE 

0422 

0009 

0424 

0000 

FI 

FI 

FI 

0426  9E08  SET 

0428  END  S3  SNAP  OUT 
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0428  CO  NF INE  ME  NT_CHECK  PEOCEDORE 

i ** ** ** * ** ************* *********** 

!  SERVICE  ROUTINE  TO  VERIFY 
!  CONFINEMENT  IS  NOT  VIOLATED 
!  WHEN  MEM  MGR  SUCCESS_CODE  IS 
!  RETURNED  TO  SUPERVISOR. 

i ********************************* 

!  REGISTER  USE: 

!  PARAMETERS 
!  RO tSUCCESS _CODE 

i ********************************* 


ENTRY 


0428 

0B00 

042A 

000A 

042C 

5E0E 

0  42E 

0438* 

0430 

5F00 

0432 

059  A 

0434 

5E08 

0436 

04B4  • 

0438 

0B00 

0  43A 

000B 

043C 

5E0E 

043E 

0448* 

0440 

5F00 

0442 

059A 

0444 

5E08 

0446 

04B4 ' 

0448 

0B00 

044  A 

0017 

0  44C 

5E0E 

044E 

0458  • 

0450 

5FOO 

0452 

059  A 

0454 

5E08 

0456 

04B4 ' 

0458 

0B00 

0  4  5  A 

0014 

045C 

5E0E 

045E 

0468' 

0460 

5FOO 

0462 

059  A 

0464 

5E08 

0466 

04B4 ' 

0468 

0B00 

0  46A 

OOOC 

IF  RO 

CASE  #LEAF  SEG_EXISTS  THEN 
CALL  MONITOR 


CASE  #NO_LEAF_EXISTS  THEN 
CALL  MONITOR 


CASE  # ALI AS_DOES_NOT_EXIST  THEN 
CALL  MONITOR 


CASE  #NO_CHILD_TO_D  ELETE  THEN 
CALL  MONITOR 


CASE  #G_AST_FULL  THEN 
CALL  MONITOR 
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0  46C 

5E0E 

046E 

0478* 

0470 

5F00 

0472 

059A 

0474 

5E08 

0476 

04B4  * 

0478 

0B00 

047  A 

000D 

0  47C 

5E0E 

047E 

0488* 

0480 

5F00 

0482 

05  9A 

0484 

5E08 

0486 

0484  * 

0488 

0B00 

048A 

0010 

048C 

5E0E 

048E 

0498* 

0490 

5F00 

0492 

059A 

0494 

5E08 

0496 

0434  • 

0498 

0B00 

049A 

0011 

049C 

5E0E 

049E 

04A8* 

04A0 

5F00 

04A2 

059A 

04A4 

5E08 

04A6 

04B4  • 

04A8 

0B00 

04  AA 

0015 

04  AC 

5E0E 

04  AE 

04  B4  ' 

04B0 

5F00 

04B2 

059A 

04B4 

9E08 

04B6 

CASE  #L_AST_FOLL  THEN 
CALL  MONITOR 


CASE  # LOC AL_ MEMOS Y_FU LL  THEN 
CALL  MONITOR 


CASS  #GLOBAL_MEMORY_FULL  THEN 
CALL  MONITOR 


CASE  #SEC_STOR_FULL  THEN 
CALL  MONITOR 


FI 

RET 

END  CONFINEMENT  CHECK 


END  SEG  MGR 
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Appendix  I 

NON -DISCRETIONARY  SECOBITI  LISTINGS 
Z8000ASM  2.02 

LOC  OBJ  CODE  STMT  SOURCE  STATEMENT 

SLISTON  $TTY 
N DS  MODULE 

CONSTANT 

TRUE  : =1 

FALSE  :  =0 

INTERNAL 

$  SECTION  ACC_CL ASS_DCL  !NOTE:  IS  AN  OVERLAY, 

IE  NO  ALLOCATION 
OF  MEMORY! 

SABS  0 

0000  ACCESS_CLASS  RECORD  [ LEVEL  INTEGER 

CAT  INTEGER] 

GLOBAL 

SSECTION  NDS_PROC 

0000  CLASS_EQ  PROCEDURE 

t  ******************************* 

!  PASSED  PARAMETERS  ! 

!  RR2  =  CLASS  1  ! 

!  RR4  =  CLASS2  ! 

!  RETURNED  ! 

!  R 1  =  CONDITION_CODE  ! 

;  ****************************** | 


ENTRY 

0000 

9042 

CPL 

RR2 , RR  4 

0002 

5E0E 

IF 

EQ 

THEN 

0004 

000E ' 

0006 

2101 

LD 

R  1  , #TRUE 

0008 

0001 

000A 

5E08 

ELSE 

OOOC 

0012* 

000E 

2101 

LD 

R  1  , #F  ALSE 

0010 

0000 

FI 

0012 

9E08 

RET 

00  14 

END  CLASS 

_EQ 

385 


0014  CL  AS  S_G  E  PROCEDURE 

I ****************************** 

!  PASSED  P  ARAMET  ERS 
!  RR  2  =  CLASS  1 
!  RR4  =  CL  ASS  2 
!  RETURNED  PARAMETER 
!  R1  =  CO  NDITION_CODE 

j  ****************************** 

ENTRY 


0014 

91F2 

PUS  HL 

3R15,RR2  SPUSH  CLASS1  ON  STACK- 

-REFER  BY  ADDR 

0016 

A1FD 

LD 

R 1 3  rR  15  !  CLASS1  ADDR  ! 

0018 

91F4 

PUS  HL 

3R15,RR4 

00  1 A 

A1FE 

LD 

R 1 4 , R  1 5  !  CLASS2  ADDR  ! 

001C 

31E7 

LD 

R7  ,  R 1 4  (#ACCESS_CLASS.  CAT) 

1  CAT 2  IN  R7  ! 

00  IE 

0002 

0020 

45D7 

OR 

R7,  ACCESS  CLASS. CAT  (R13) 

! CAT  1  OR  CAT2,  R7! 

0022 

0002 

0024 

4BD7 

CP 

R7  ,  ACCESS_CLASS  .CAT  (R13) 

I C ATI = (CAT1  OR  CAT2) ? ! 

0026 

0002 

0028 

5E0E 

IF  EQ 

THEN 

002A 

0048 ' 

002C 

61D6 

LD 

R6,ACCESS_CLASS. LEVEL (R13) 

! LEVEL  1 ! 

002E 

0000 

j 

COMPARE  LEV  EL  1  WITH  LEVEL2  ! 

0030 

4BE6 

CP 

R6,ACCESS_CLASS. LEVEL (R14) 

0032 

0000 

0034 

5E0 1 

IF 

GE  THEN  ! LEV ELI  GE  LEVEL2 

0036 

0040* 

0038 

2101 

LD  R1,#TRUE 

003  A 

0001 

003C 

5E08 

ELSE 

003E 

0044' 

0040 

2101 

LD  R 1 , #FALSE 

0042 

0000 

FI 

0044 

5E08 

ELSE 

0046 

004C  * 

0048 

2101 

LD 

R  1 ,  #F ALSE 

004  A 

0000 

FI 

004C 

95F4 

POPL 

RR4, 3R1 5 

004  E 

95F2 

POPL 

RR2,o>R15  IRESTORE  STACK! 

0050 

9E08 

RET 

0052 

END  CLASS  GE 

END 

NDS 
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Appendix  J 

ME  MOST  MANAGER  LISTINGS 


Z8000ASM  2.02 

LOC  OBJ  CODE  STMT  SOURCE  STATEMENT 

SLISTON  $TTY 

MM_  PROCESS  MODULE 

!  VERS.  1.9  ! 


CONSTANT 

RETURN  TO  MONITOR 


COUNT  :=  10 
TIME  :=  500 


XA902  JHBUG  REENTRY 


NR_OF_HOSTS 

g_ast!limit 

G_AST_FULL 

?REE_ENTRY 

TRUE 

FALSE 

SPACE 

DASH 


=  2 
=  10 
=  12 

=  XEEEEEEEE 
=  SBBBB 
=  XCCCC 
=  %20 
=  %2D 


10  MGR 


=  X60 


FILE_MGR  :=  X40 

MEM_MGR  :=  %00 

FM_ENTRY  :=  X4A00 

IO_ENTRY  :=  X4E00 

CRE ATE_ENTRY_CODE 
I NVALID_MMGR~CODE 

oelete.entryIcode 
ACTIV  ATE_S  EG_CODE 
DEACTIV  ATE_SEG_CODE 
SWAP  IN  SEG  CODE 


50 
60 

51 

52 

53 

54 


SWAP  OUT  SEG  CODE 


55 


SUCCEEDED  :=  2 
STK_SIZE  :=  1 
TOP_SECRET  :=  4 
SECRET  :=  3 
CONFIDENTIAL  :=  2 
UNCLASS  :=  1 
EMPTY  :=  0 
CRYPTO  :=  1 
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NATO 

NUCLEAR 


2 

4 


TYPE 

ADDRESS  WORD 

H_ARRAY  ARRAY[  3  WORD] 

G  AST  REC  RECORD 


UNI QU  E_I D 

LONG 

GLOBAL  ADDR 

ADDRESS 

P  L  ASTE  NO 

WORD 

FLAG_BITS 

WORD 

G_ASTE_PAR 

WORD 

NO  ACT~I N  MEM 

WORD 

NO  ACT~DEP 

BYTE 

SIZE1 

BYTE 

PG_TBL_LOC 

ADDRESS 

ALIAS  TBL  LOC 

ADDRESS 

SEQUENCER 
EVENT  1 
EVENT2 

] 

EXTERNAL 
SIGNAL 
WAIT 
TC  IN IT 
GET_CPU_NO 
CREAT E_PROCESS 
SNDCHR 
S  NDMSG 
SNDCRLF 

G_AST_LOCK 
G_AST  ARRAY[G_AST_LIMIT  G_AST_REC  ] 
GLOBAL 

SSECTION  MM_DATA 

MM  ENTRY  LABEL 


LONG 

LONG 

LONG 


PROCEDURE 

PROCEDURE 

PROCEDURE 

PROCEDURE 

PROCEDURE 

PROCEDURE 

PROCEDURE 

PROCEDURE 

WORD 
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INTERNAL 

j  *  *  *  *  MESSAGES  *  *  *  *  i 

0000 

08 

28 

10  ARRAY  [*  BYTE]  :=  • %08 (FOR  10)' 

0002 

46 

4F 

0004 

52 

20 

0006 

49 

4F 

0008 

29 

0009 

08 

29 

FH  ARRAY  [  *  BYTE]  :=  *%08(F0R  FM)  • 

0003 

46 

4  F 

000D 

52 

20 

OOOF 

46 

4  D 

0011 

29 

00  12 

12 

4B 

MM_MSG_1 

ARRAY  [*  BYTE]  :=  ' X12KERNEL  =  SIGNALLER' 

0014 

45 

52 

0016 

4E 

45 

0018 

4C 

20 

0  0 1 A 

3D 

20 

001C 

53 

49 

001E 

47 

4  E 

0020 

41 

4C 

0022 

4C 

45 

0024 

52 

0025 

10 

4D 

CREATE  MSG 

ARRAY  [*  BYTE  ]: =  'X10MM:  CREA  TE_E  NTRY ' 

0027 

4D 

3A 

0029 

20 

43 

002B 

52 

45 

002D 

41 

54 

002F 

45 

5F 

0031 

45 

4  E 

0033 

54 

52 

0035 

59 

0036 

10 

4D 

DELETE_MSG 

ARRAY  [*  BYTE]  :=  ' X10MM:  DELETE_ENTR Y ' 

0038 

4D 

3A 

003A 

20 

44 

003C 

45 

4C 

003E 

45 

54 

0040 

45 

5F 

0042 

45 

4  E 

0044 

54 

52 

0046 

59 

339 


0047 

OC 

40 

ACTI VATE_MSG 

ARRAY  [*  BYTE] 

:  = 

*  SOCMM:  ACTIVATE* 

0049 

4D 

3A 

0  04  B 

20 

41 

0  04D 

43 

54 

004F 

49 

56 

0051 

41 

54 

0053 

45 

0054 

OE 

4D 

DEACTIVATE_MSG 

ARRAY  [ *  BYTE  ] 

:  = 

*  SOEMM :  DEACTIVATE' 

0056 

4D 

3  A 

0058 

20 

44 

00  5A 

45 

41 

005C 

43 

54 

005E 

49 

56 

0060 

41 

54 

0062 

45 

0063 

OB 

4D 

SWAP_IN_MSG 

ARRAY  [ *  BYTE  ] 

•SOBMM:  SWAP_IN ' 

0065 

4D 

3A 

0067 

20 

53 

0069 

57 

41 

006B 

50 

5F 

006D 

49 

4E 

006F 

OC 

4D 

SWAP  OOT  MSG 

ARRAY  [ *  BYTE  ] 

i  = 

'SOCMM:  SWAP_OOT* 

0071 

4D 

3A 

0073 

20 

53 

0075 

57 

41 

0077 

50 

5F 

0079 

4F 

55 

007B 

54 

007C 

OC 

49 

ERROR_MSG 

ARRAY  [*  BYTE] 

•  — 

*  XOCINVALID  CODE* 

007E 

4E 

56 

0080 

41 

4C 

0082 

49 

44 

0084 

20 

43 

0086 

4F 

44 

0088 

45 

0089 

02 

00 

RST_VALUES 

ARRAY  [*  BYTE] 

:  = 

[ 2,0, 0,0,0, 16,0,17, 

0  08  B 

00 

00 

008D 

00 

10 

0  08F 

00 

1  1 

0091 

00 

03 

0093 

00 

01 

0095 

00 

30 

0097 

00 

00 

1,0,4 

099  A 

MM_MSG_ARRAY  ARRAY  [  8  WORD  ] 

00AA 

SENDER  WORD 
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SABS  0 

! NO  MEMORY  ALLOCATED;  USED 
FOR  PARAMETER  TEMPLATE  ONLY 

0000 

[ 


] 

SABS  0 

•NO  MEMORY  ALLOCATED;  USED 
FOR  PARAMETER  TEMPLATE  ONLY 


ACTIVATE_ARG 
CODE 
DBR 

HANDLE 
ENTRY  NO 
SEG  NO 


RECORD 
WORD 
WORD 
H_ARR  AY 
BYTE 
BYTE 


RET_VAL 

RECORD 

CODE  1 

BYTE 

FILLER 

BYTE 

MM_HANDLE 

H  ARRAY 

CLASS 

LONG 

SIZE 

WORD 

FILLER  1 

WORD 

SABS  0 

A  RG_LI  ST 

RECORD 

REG 

ARRAY[  13  WORD  ] 

IC 

WORD 

C?U_ID 

WORD 

SAC 

LONG 

PRI 

WORD 

USR_STK 

WORD 

K  ER_ST  K 

WORD 
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0000 

0000 

0002 

0004 

0  0  06 

0008 

00  0  A 

000C 

OOOE 

0010 

0012 

00  14 

0016 

0018 

00  1 A 

001C 

0  0  IE 

0020 

0022 

0024 

0026 

0028 

002A 

002C 

002E 

0030 

0032 

0034 

0036 

0038 

003A 

003C 

003E 

0040 

0042 

0044 

0046 


SSECTION  MM  PROC 


MM_MAIN  PROCEDURE 

ENTRY 
MM_ENTRY: 

!  INITIALIZE  G  AST  ! 


4D08 

CLR 

G_AST_LOCK 

0000* 

2102 

LD 

R2 ,  #1 

0001 

2101 

LD 

R1  ,  #0 

0000 

1404 

LDL 

RR4 ,  #FREE_ENTRY 

EEEE 

EEEE 

5D14 

DO 

LDL 

G_AST .  UNIQUE_ID  (R 1)  ,  RR4 

0000* 

A920 

INC 

R2,  #1 

0B02 

CP 

R2,  #G_ AST_LIM IT 

000  A 
5E02 

IF 

GT  ! END  OF  G  AST!  THEN 

0024 ' 
5E08 

EXIT  FI 

002A* 

0101 

ADD 

HI,  tSIZEOF  G_AST_REC 

00  20 
E8F4 

OD 

2101 

LD 

!  RESERVE  FIRST  ENTRY  IN 

G  AST  FOR  ROOT  ! 

R 1  ,  #0 

0000 

1404 

LDL 

RR4,  #-1 

FFFF 

FFFF 

5D14 

LDL 

G_AST.  UNIQUE_ID  (R1)  ,  RR4 

0000* 

5F00 

CALL 

GET_CPU_NO  ! RETURNS: 

0000* 

93P1 

PUSH 

HI:  CPU  # 

R2:  #  VP'S! 
3>R15,  R 1  ISAVE  CPU  #! 

5F00 

CALL 

TC  INIT 

0000* 

!  USES/HOST  #  I 

210D 

LD 

R13,  #0 

0000 

!  INITIALIZE  USERS  ! 
DO 

A9D0  INC  S13,  *1 
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0  048 

OBOD 

CP 

R13,  #NR_OF_HOSTS 

0  04A 

0002 

IF  GT 

1  .'ALL  HOSTS  INITIALIZED! 

0  04C 

5E02 

THEN 

EXIT 

004E 

0054’ 

0050 

5E08 

0052 

00B8  * 

FI 

!  CREATE  FM  PROCESS  ! 

0054 

21F0 

LD 

RO,  dRI 5  ! RESTORE  CPU 

#! 

0056 

030F 

SUB 

R 1 5r  #S IZEOF  ARG_LIST 

0058 

0028 

!  SETS 

ARGUMENT  LIST  IN  STAC 

K! 

005A 

A1F1 

LD 

R1,  R15 

005C 

6F10 

LD 

ARG  LIST. CPU  ID (R 1 ) ,  RO 

005E 

001C 

!  LOAD 

i  INITIAL  REGISTER  PARAMETERS 

FOR 

FM  PROCESS  (SIMULATED) 

R 1  3 

DENOTES  USER  #  ! 

0060 

5C19 

LDM 

A  RG_LIST.  REG  (R1)  ,  R2  , 

#13 

0062 

020C 

0064 

0000 

0066 

2102 

LD 

R2,  #FM_ ENTRY 

0068 

4A00 

006A 

6F12 

LD 

ARG_LIST.IC (R1)  ,  R2 

006C 

00  1 A 

006E 

2102 

LD 

R2 ,  ^SECRET 

0070 

0003 

0072 

8D38 

CLR 

R3 

0074 

0503 

OR 

R  3 ,  #CR  YPTO 

0076 

0001 

0078 

5D12 

LDL 

ARG_LIST.SAC  (S  1 )  ,  RR2 

007A 

00  1  E 

0  07C 

4D15 

LD 

ARG_LIST.PRI  (R  1)  ,  #2 

0  07E 

0022 

0080 

0002 

0082 

4D15 

LD 

ARG_LIST.USR_STK  (R1)  , 

#STK_SIZ  E 

0084 

0024 

0086 

0001 

0088 

4D15 

LD 

A RG_LIST . KER_STK  (R 1)  , 

#SIK_SIZE 

008A 

0026 

0  08C 

0001 

0  08E 

A1  IE 

LD 

R14,  R 1 

0090 

93FD 

PUSH 

3R15,  R 13 

0092 

5FOO 

CALL 

C  REATE_ PROCESS  !R14:  ARG  PTR! 

0094 

0000* 

0096 

97FD 

POP 

R  1 3 ,  5R15 

!  CREATE  10  PROCESS  I 
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HI,  R 1 5  'RESTORE  ARGUMENT  PTR! 


0098  A  IF  1  LD 


!LOAD  INITIAL  REGISTER  PARAMETERS 
FOR  10  PROCESS  (SIMULATED) 

R 1 3  DENOTES  USER  #  ! 


009  A 

5C19 

LDM 

ARG  LIST. REG  (R1)  ,  R2,  #13 

009C 

020C 

009E 

0000 

00  AO 

2102 

LD 

R  2 

,  #IO_ENTR Y 

00A2 

4E00 

00A4 

6F12 

LD 

ARG_LIST.IC (R1)  ,  R2 

00A6 

00 1 A 

00A8 

A1  IE 

LD 

R  1 4 ,  R  1 

OOAA 

93FD 

PUSH 

3R15,  R 1 3 

0  0  AC 

5F00 

CALL 

CREATE  PROCESS  ! R14:  ARG  PTR! 

OOAE 

0000* 

OOBO 

97FD 

POP 

R  1 3,  a>R  1 5 

00B2 

0 1 0F 

ADD 

R 1 5,  #SIZEOF  ARG  LIST 

0  0B4 

0028 

00B6 

E8C7 

OD 

!  REMOVE 

CPU  #  FROM  STACK  ! 

00B8 

97F0 

POP 

RO, 

a)R  15 

DO  !** 

DO 

FOREVER  **! 

OOBA 

7608 

LDA 

R8,MM_MSG_ARR AY  0 

OOBC 

009A* 

OOBE 

5F00 

CALL 

WAIT 

OOCO 

0000* 

00C2 

6F01 

LD 

SENDER,  R 1  'SAVE  SIGNALING 

00C4 

OOAA' 

00C6 

2103 

LD 

R3 , #50 

00C8 

0032 

OOCA 

5F00 

CALL 

MM_PRINT_ BLANKS 

OOCC 

030C' 

OOCE 

2102 

LD 

R2,#MM_MSG_1 

OODO 

0012* 

00D2 

5F00 

CALL 

SNDMSG 

00D4 

0000* 

0  0D6 

6101 

LD 

R1, SENDER 

0  0D8 

OOAA' 

IF 

HI 

OODA 

OBO  1 

CASE 

#IO_MGR  THEN  LD  R2,#I0 

0  0  DC 

0060 

OODE 

5E0E 

OOEO 

OOEE' 

00E2 

2102 

00E4 

0000' 

00E6 

5F00 

CALL  SNDMSG 

00E8 

0000* 

OOEA 

5E08 

CASE 

#FILE_MGR  THEN  LD  R2,#FM 

OOEC 

OOFE' 

OOEE 

OBO  1 

OOFO 

0040 

00F2 

5E0E 
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0  0F4 

OOFE' 

0  0F6 

2102 

OOF8 

0009* 

00FA 

5F00 

OOFC 

0000* 

FI 

00  FE 

5F00 

CALL 

0100 

02D8  • 

0102 

5F00 

CALL 

0104 

0000* 

0  106 

2103 

LD 

0108 

0032 

0  10A 

5F00 

CALL 

010C 

030C  * 

0  1 0E 

6101 

LD 

0110 

009  A 1 

LL  SNDMSG 

MM_DELAY 
SNDCSLF 
R3, #50 

MM_PRINT_ BLANKS 
R 1 , MM_MSG_ARR AY  0 
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IF  R 1 


0  112 

0B0  1 

CASE  #CREATE_ENTRY_CODE  THEN 

0114 

0032 

01  16 

5E0E 

0118 

0122* 

0  1  1  A 

5F00 

CALL  CREATE_E  NTRY 

0  1  1C 

0 19E  • 

01  IE 

5E08 

CASE  #DELETE_ENTRY_CODE  THEN 

0120 

0176' 

0122 

OB0 1 

0  124 

0033 

0126 

5E0E 

0128 

0132* 

012A 

5F00 

CALL  DELETE.ENTRY 

012C 

01  AC' 

012E 

5E08 

CASE  #ACTIVATE_SEG_CODE  THEN 

0130 

0176' 

0132 

OB0 1 

0134 

0034 

0136 

5E0E 

0138 

0142' 

013A 

5F00 

CALL  ACTIVATE 

013C 

0 1  BA ' 

0  13E 

5E08 

CASE  #DEACTIVATE_SEG_CODE  THEN 

0140 

0176' 

0142 

0B01 

0144 

0035 

0146 

5E0E 

0  148 

0152* 

0  1  4  A 

5F00 

CALL  DEACTIVATE 

0  14C 

029E' 

0143 

5E08 

CASE  #SWAP_IN_SEG_CODE  THEN 

0150 

0176* 

0152 

OBO  1 

0154 

0036 

0  156 

5E0E 

0158 

0162* 

015A 

5F00 

CALL  SWAP_IN 

015C 

02AC  • 

0  15E 

5E08 

CASE  #SWAP_OUT_SEG_CODE  THEN 

0160 

0176* 

0162 

OBO  1 

0  164 

0037 

0166 

5E0E 

0168 

0172* 

0  16A 

5F00 

CALL  SWAP_OUT 

0  16C 

02CA* 

0  16E 

5E08 

ELSE 

0  170 

0176* 

0172 

2102 

LD  B2 , #ERROR_HSG 

0174 

007C’ 

FI 
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0176 

5F00 

CALL 

SNDMSG 

0178 

0000* 

017A 

5F00 

CALL 

MM_DELAY 

017C 

02D8 ' 

017E 

5F00 

CALL 

SNDCRLF 

0  180 

0000* 

0182 

2103 

LD 

R3, #75 

0  184 

004B 

0186 

5F00 

CALL 

MM_PRINT_LINE 

0188 

02F4 ' 

018A 

5F00 

CALL 

SNDCRLF 

0  18C 

0000* 

•  ** 

SIGNAL  (SENDER,  'DONE')  * 

0  18E 

6101 

LD 

HI,  SENDER 

0190 

00  AA ' 

0192 

7608 

LDA 

R8,MM_MSG_ARRAY  0 

0194 

009A ' 

0196 

5F00 

CALL 

SIGNAL 

0198 

0000* 

019A 

E88F 

OD  !  **  REPEAT  FOREVER  **  ! 

019C 

9E08 

RET 

019E 

END  MM, 

MAIN 

0  19E 

CREATE, 

ENTRY  PROCEDURE 

ENTRY 

019E 

7608 

LDA 

R8 , MM_MSG_ARR  AY  0 

0  1  AO 

009  A ' 

0  1A2 

0C85 

LDB 

3>R8,#SUCCEEDED 

01  A4 

0202 

01A6 

2102 

LD 

R 2,  #CREATE_MSG 

01A8 

0025* 

0  1  AA 

9E08 

RET 

01  AC 

END  CRE AT E_E NTRY 

01  AC 

DELETE, 

ENTRY  PROCEDURE 

ENTRY 

0  1  AC 

7608 

LDA 

R8 , MM_MSG_ARR  AY  0 

0  1  AE 

009  A  • 

01  BO 

0C85 

LDB 

a>R 8  ,  # SUCCEEDED 

01B2 

0202 

0  1B4 

2102 

LD 

R2,#DELETE_MSG 

01B6 

0036* 

0  1B8 

9E08 

RET 

0  1  BA 

END  DELETE  ENTRY 
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0  1  BA 

ACTIVATE  PBOCEDUBE 

!  B8 :  ARGUMENT  PTR  ! 

ENTRY 

0  1  BA 

7608 

LDA 

R8 ,  MM_MSG_ARR AY  0 

0  1 BC 

009  A ' 

01  BE 

6182 

LD 

R2 ,  ACTIVATE_ARG. HANDLE  2  (R8) 

IUNIQUE  ID! 

0  ICO 

0008 

0  1C2 

8D38 

CLR 

R3 

01C4 

608B 

LDB 

RL  3  ,  ACTIVATE_ARG . ENTRY _NO (R8) 

01C6 

000  A 

0  1C8 

030F 

SOB 

HI  5,  #SI ZEOF  RET_VAL 

0  1 CA 

0010 

0  ICC 

A1F8 

LD 

R8  ,  R 1 5 

0  ICE 

2100 

LD 

RO  ,  #FALSE 

0  IDO 

CCCC 

01D2 

2101 

LD 

R1  ,  #0  ! G_AST  INDEX! 

01D4 

0000 

01D6 

2104 

LD 

R4  ,  *1  ! NR  OF  ENTRIES  SEARCHED 

0  1D8 

0001 

SEARCH_G_AST: 

DO 

0  1 D  A 

5012 

CPL 

RR2 r  G_AST.  UNIQUE_ID  (R1) 

0  1  DC 

0000* 

0  1  DE 

5E0E 

IF 

EQ  '.SEGMENT  IS  ACTIVE!  THEN 

0  1  EO 

01EA' 

01E2 

2100 

LD 

RO,  #TRUE 

0  1E4 

BBBB 

01E6 

5E08 

EXIT  FROM  SEARCH  G  AST 

0  1E8 

01FE' 

FI 

0  1 EA 

A940 

INC 

R  4  ,  #1 

01  EC 

0B04 

CP 

R  4 ,  #G_ASI_LIMIT 

0  1  EE 

OOOA 

0  1 FO 

5E02 

IF 

GT  ! END  OF  G_AST !  THEN 

01F2 

0  1 F8 ' 

01F4 

5E08 

EXIT  FROM  SEARCH  G  AST 

01F6 

01  FE' 

FI 

01F8 

0101 

ADD 

HI,  #SI ZEOF  G_AST_REC 

0  1  FA 

0020 

0  1 FC 

E8EE 

OD 

0  1  FE 

OBOO 

CP 

RO,  #FALSE 

0200 

CCCC 

IF  EQ 

!  SEGMENT  NOT  ACTIVE! 

0202 

5E0E 

THEN 

0204 

0266' 

0206 

2100 

LD 

RO,  *1 

0208 

0001 

020A 

2101 

LD 

R  1  ,  #0 
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020C  0000 


020E  1404 
0210  EEEE 
0212  EEEE 
0214  5014 
0216  0000* 
0218  5E0E 
0 2 1 A  0220 ' 
0 2  1C  5E08 
0 2  IE  0234' 


FIND  FREE  ENTRY: 


LDL 

RR4 , 

#FREE_ENTRY 

CPL 

RR4 , 

G_AST.UNIQUE_ID (R1) 

IF  EQ  'ENTRY  IS  AVAILABLE!  THEN 
EXIT  FROM  FIND  FREE  ENTRY 


0220  A900 
0222  0B00 
0224  000A 
0226  5E02 
0228  0223* 
022A  5E08 
022C  0234* 


FI 

INC  RO ,  #1 

CP  RO,  #G_AST_LIMIT 

IF  GT  ! END  OF  G_AST !  THEN 

EXIT  FROM  FIND  FREE  ENTRY 


FI 

022E  0101  ADD  R1,  tSIZEOF  G_AST_REC 

0230  0020 

0232  E8ED  OD 


0234  0B00 
0236  000 A 

0238  5E0A 
023A  025C' 
023C  5D12 
023E  0000* 

0240  1404 
0242  0000 
0244  0000 
0246  5D14 
0248  0014* 
0  24  A  5D14 
0  24C  0018* 
0  24  E  5D14 
0250  001C* 
0252  4C35 
0254  0000 
0256  0202 


CP  RO,  #G_AST_LIMIT 

IF  LS  'FOUND  FREE  ENTRY! 

THEN 

LDL  G_AST. UNIQUE_ID(R1)  ,  RR2 

!  ZERO  ALL  EVENT  DATA  ENTRIES  ! 
LDL  RR4,  #0 

LDL  G_AST.  SEQUENCER  (R  1)  ,  RR4 
LDL  G_AST . EVE  NT  1 (R1 )  ,  RR4 
LDL  G_AST. EVENT2 (R1) ,  RR4 
LDB  RET_VAL.CODE1  (R8)  ,  ^SUCCEEDED 


0258  5E08  ELSE 

0  25 A  0262' 

0 25C  4C85  LDB  RET_VAL. CODE1  (R 8)  ,  #G_AST_FULL 

0  25E  0000 
0260  OCOC 

FI 

0262  5E08  ELSE  ! SEGMENT  ACTIVE! 


399 


0264 

026C  * 

0266 

4C85 

LDB 

RET  VAL.C0DE1  (R8)  ,  f SUCCEEDED 

0268 

0000 

0  26  A 

0202 

FI 

0  26C 

5D82 

LDL 

RET_V AL  .  Mii_H  A  NDLE  0  (R8)  , 

RR2 

026E 

0002 

0270 

6P81 

LD 

RET_VAL.  tm_HANDLE  2  (R8)  , 

R  1 

0272 

0006 

0274 

1404 

LDL 

RR4,  #*30001 

0276 

0003 

0278 

0001 

0  27A 

5D84 

LDL 

RET_VAL.  CLASS  (R8)  ,  HR 4 

027C 

0008 

027E 

4D85 

LD 

RET_VAL. SIZE (R8)  ,  #1 

0280 

oooc 

0282 

0001 

0284 

7689 

LDA 

R9,  RET_VAL(R8) 

0286 

0000 

0288 

7608 

LDA 

R8,  MM_MSG_ARRAY  0 

028A 

009A* 

0  28C 

2102 

LD 

R2 ,  #16 

028E 

0010 

0290 

BA91 

LDIRB 

a>R  8  ,  a)R9,  R2 

0292 

0280 

0  294 

2102 

LD 

R2,  #  ACTI  VATE__aSG 

0296 

0047* 

0298 

010F 

ADD 

R15,  #SI ZEOF  RET_VAL 

029A 

0010 

029C 

9E08 

SET 

029E 

END  ACTIVATE 
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029E 

DEACTIVATE  PROCEDUBE 

ENTRY 

029E 

02A0 

7608 
009  A ' 

LDA 

R8 ,MH_MSG_ARRAY  0 

02A2 

02A4 

0C85 

0202 

LDB 

<BR8r#SUCCEEDED 

02A6 

02A8 

2102 

0054* 

LD 

R2 , #DEACTIVATE_MSG 

02  AA 

9E08 

RET 

0  2  AC 

END  DEACTIVATE 

0  2AC 

SWAP_IN 

ENTRY 

'  PROCEDURE 

02AC 

02AE 

2102 

FF30 

LD 

R2 ,  #SFF30 

0  2BO 
0232 

3B26 

FFD2 

OUT 

SFFD2,  R  2 

02B4 

02B6 

7608 
009  A' 

LDA 

R8 ,  MH_HSG_ARRAY 

02B8 

02BA 

5F00 

0000* 

CALL 

WAIT  !R8:NSG  ARRAY! 

0  2BC 
02BE 

7608 
009  A ' 

LDA 

R8 ,MM_MSG_ARRAY  0 

0  2C0 
02C2 

0C85 

0202 

LDB 

3R8,#SUCCEEDED 

02C4 

02C6 

2102 
0063  • 

LD 

R2 , #SWAP_IN_MSG 

02C8 

9E08 

SET 

02CA 

END  SWAP_I N 
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PfiOCEDUBE 


02CA 

SWAP_ 

ENTRY 

OUT 

0  2CA 
02CC 

7608 
009  A ' 

LDA 

R8 , MM_MSG_ARR AY  0 

02CE 

02D0 

0C85 

0202 

LDB 

a)R  8  r  #SUCCEEDED 

02D2 
0  2D4 

2102 

006F' 

LD 

R2  ,  #SWAP_OUT_MSG 

02D6 

9E08 

RET 

02D8 

END  SWAP_OUT 

02D8  MM_DELAY  PROCEDURE 

; ********************************** 

!  PRODUCES  2  SEC  DELAY  I 

; ********************************* j 


ENTRY 

02D8 

2102 

LD 

R2r 

#COUNT 

0  2DA 

000A 

0  2DC 

2101 

LD 

HI* 

#TIME 

02DE 

01F4 

DO 

0  2E0 

0B02 

CP 

R2, 

#0 

0  2E2 

0000 

0  2E4 

5E0E 

IF  EQ 

THEN 

EXIT  FI 

02E6 

02EC ' 

0  2E8 

5E08 

02EA 

02F2* 

0  2EC 

AB20 

DEC 

R2 

0  2EE 

7B 1 D 

MREQ 

R1 

02F0 

E8F7 

OD 

02F2 

9E08 

RET 

0  2F4 

END  MM_DELAY 
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0  2F4  MM_PRINT_LINE  PROCEDURE 

t ************************ ********* 

!  PRINTS  LINE  LENGTH 
!  SPEC  IN  R 3. 

i ********************************* 


0  2F4 

C82D 

ENTRY 

LDB 

RL0 , 

#  DASH 

02F6 

0B03 

DO 

CP 

R3, 

#0 

0  2F8 
02FA 

0000 

5E0E 

IF 

EQ  THEN 

EXIT  FI 

0  2FC 
0  2FE 
0300 
0302 

0302* 
5E08 
030  A* 
5F00 

CALL  SNDCHR 

0304 

0306 

0000* 

AB30 

DEC 

R3 

0308 

030A 

E8F6 

9E08 

OD 

RET 

0  30C 

END  MM 

_PRINT_LINE 

0  30C  M M _P HI NT_ BLANKS  PROCEDURE 

j  ********************************* 

!  PRINTS  NUMBER  OF 
!  BLANKS  SPEC  IN  R3. 

;  ********************************* 


03  OC 

C820 

ENTRY 

LDB 

RLO , 

#SPACE 

030E 

0B03 

DO 

CP 

R3, 

#0 

0310 

0312 

0000 

5E0E 

IF  E 

Q  THEN 

EXIT  FI 

0314 
0316 
0318 
03  1 A 

03  1  A' 
5E08 
0322* 
5F00 

CALL 

SNDCHR 

0  3  1C 
03  IE 

0000* 

AB30 

DEC 

R3 

0320 

0322 

0324 

E8F6 
9E0  8 

OD 

RET 

END  MM 

PRINT 

BLANKS 

END 

MM_PROCE  SS 
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